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ABSTRACT 


The Navy has developed Distance Support tools to support specific naval systems. These 
tools often do not facilitate knowledge retention and reutilization; to resolve this problem, 
a Data Aggregation System (DAS) was recommended to aggregate and integrate data to 
improve fleet readiness. A systems engineering (SE) process, derived from the 2009 
Department of Defense (DoD) SE Model, was used to develop the DAS. Based on past 
Navy lead Distance Support studies and completed surveys, the team determined the 
stakeholders needed a data aggregation system that provides 1) easily accessible data, 
2) high quality information, 3) current data, 4) well organized information, and 
5) information reported on demand. The team conducted requirements analysis to trace 
and prioritize the system requirements to stakeholders’ needs. The requirements were 
then mapped to functions. The high level system functions identified were 1) obtain data, 
2) process data, 3) analyze data, 4) report data, and 5) display data. An analysis of 
Alternatives (AoA) using gap analysis yielded two feasible solutions, 1) modify the 
Engineering and Supportability Decision System (ESDS) and 2) develop a new system. 
The results of cost and risk recommended the modified ESDS solution. The solution 
architecture was documented using Vitech’s CORE® software suite. 
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EXECUTIVE SUMMARY 


The Navy has developed several Distance Support tools to support specific naval 
systems. These tools often do not facilitate knowledge retention and reutilization. A Data 
Aggregation System (DAS) was proposed to aggregate and integrate data as well as to 
capture knowledge to improve fleet readiness. The team’s recommendation is to 
implement a Data Aggregation System (DAS) which modifies the existing Engineering 
and Supportability Decision System (ESDS), to retain technical and supportability data as 
well as aggregate and integrate information in a timely manner. 

This report describes the requirements and parameters necessary to provide a 
technically feasible, cost effective, and efficient solution that Naval Surface Warfare 
Center, Port Hueneme Division (NSWC PHD) can further develop to provide Distance 
Support to the United States Navy (USN). Distance Support is defined by the Chief of 
Naval Operations (CNO) as “a Navy Enterprise effort that combines people, processes, 
and technology into a collaborative infrastructure without regard to geographic location” 
(CNO 2007, 2). Specifically for NSWC PHD, Distance Support is the technical help 
provided remotely to USN ships in all areas of operation and maintenance for warfare 
systems. 

The team developed the following problem statement to more completely capture 
the issue. 

In recent years, the Navy’s decision to reduce manning and training with 
the increased complexity of combat systems as new programs emerge 
have led to a decline in Sailors’ ability to operate, maintain, and sustain 
combat systems to the levels required to meet mission readiness 
requirements (Balisle 2011). Numerous Distance Support tools currently 
used to respond to USN fleet combat system issues are often slow and 
ineffective. The eventual technical solutions are often not captured for 
knowledge retention and reutilization, nor are they available as a self-help 
tool for the war-fighters. Knowledge data that is captured is difficult to 
access and utilize in a timely manner. In addition, current Distance 
Support tools used by Subject Matter Experts (SME) to obtain and analyze 
system performance metrics are manually intensive and limited in 
capability. 
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A systems engineering (SE) approach, adapted from the 2009 Department of 
Defense (DoD) SE Model, was developed and followed to ensure the recommended DAS 
satisfied stakeholders’ needs. The first step of the SE process was to define stakeholder 
needs. Past NSWC PHD Distance Support studies and already completed surveys were 
analyzed to identify needs associated with DAS. It was determined that the stakeholders 
need a system that provides 1) easily accessible data, 2) high quality information, 
3) current data, 4) well organized information, and 5) information displayed and reported 
when needed. An operational concept diagram was developed to show, at a very high 
level, the operational relationships amongst users and the new proposed DAS. This was 
an important first step to developing a conceptual design of the system that would 
provide the stakeholders with a preferred solution. 

The second step in the SE process was to conduct requirements analysis to 
translate the needs of the stakeholders into DAS requirements. The team developed 
three categories of requirements, 1) characteristics, 2) design and construction, and 
3) component level requirements. Functional analysis was then conducted to identify the 
system resources that would be required for DAS to achieve the operational concept that 
was developed from the requirements analysis. The high level functions that were 
determined necessary to aggregate data were 1) obtain data, 2) process data, 3) analyze 
data, 4) report data, and 5) display data. 

The team conducted an Analysis of Alternatives (AoA) to determine the best 
alternative that would achieve DAS capabilities and meet the stakeholders’ needs. Six 
alternatives were identified and analyzed to determine the two most effective alternatives, 
1) build a brand new system or 2) modify and improve an existing system to meet the 
needs of the stakeholders. To determine the most feasible existing system, the team 
defined a number of evaluation measures and metrics, such as 1) the ability to access 
data, with a Threshold of 10 seconds and an Objective of 2 seconds, or 2) the Mean Time 
to Repair (MTTR), with a Threshold of 2 hours and an Objective of 1 hour. The team 
originally identified sixteen systems that could be modified to meet stakeholders’ needs. 
After using the evaluation metrics to assess each existing system’s performance based on 
their current capabilities, the team narrowed the list down to eight potential existing 
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systems. Using swing weight matrices and the Quality Function Deployment (QFD) 
House of Quality (HOQ) model, the team further reduced the list to four potential 
existing systems, 1) ESDS, 2) Aegis Combat System Reliability Maintainability and 
Supportability Database (ACSRMS), 3) Maintenance Figure of Merit (MFOM), and 
4) Material Readiness Database (MRDB). A gap analysis determined that the existing 
system with the least amount of functional gaps was ESDS. Cost Analysis was conducted 
using Constructive Systems Engineering Cost Model (COSYSMO) to compare the two 
alternatives, 1) modify ESDS (termed as ESDS+) or 2) build a new system. The results 
showed that ESDS+ would cost 60% less than building a new system, with the top cost 
drivers being system design and product evaluation. From Risk Analysis, Expert 
COSYSMO showed that ESDS+ had less risk issues than building a new system. The 
major risk area for both systems was attributed to two factors, documentation and the 
number and diversity of platforms. Thus, the results of the AoA lead the team to 
recommend modifying the existing ESDS, rather than develop a whole new system 

The third and final step in the SE process was to develop the system architecture 
for DAS and ESDS+. After defining DAS requirements and tracing them to the system 
functions, the team identified all of the relationships between the functions and 
components and entered them into Vitech’s CORE® software suite to document the 
functional architecture. The team used Integration Definition for Function Modeling 
(IDEFO) to model both the functional and physical architectures of DAS. The team also 
used a number of DoD Architecture Framework (DoDAF) products to identify the tasks, 
activities and operational elements required to complete the DAS’ mission, and to depict 
the interconnections required for DAS to function. The architecture for ESDS+ was then 
developed based on the gap analysis and documented using DODAF products and IDEFO 
models. By developing the system architecture, the team was able to apply a SE approach 
toward solving a real world problem for the Navy utilizing the knowledge and skills 
acquired from the NPS MSSE curriculum. The SE process proved to be effective at 
facilitating a thorough AoA that resulted in an architecture that satisfies the stakeholder 
needs. 
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I. 


INTRODUCTION AND PROJECT OVERVIEW 


This capstone report has been developed by a team of students at the Naval 
Postgraduate School (NPS) in the Master’s of Science in Systems Engineering (MSSE) 
Distance Learning Cohort 311-1130. The team, all employees of Naval Surface Warfare 
Center, Port Hueneme Division (NSWC PHD), followed the classic “V” model of 
systems engineering (SE), developed by Kevin Forsberg and Hal Mooz (Forsberg, Mooz, 
and Cotterman 2005). The “V” model captured succinctly what the team saw as a logical 
path for developing a customer validated system based on the customer’s needs. The 
problem was decomposed and analyzed so a solution could be designed that will be 
validated and verified by the customer. Past NSWC PHD Distance Support studies and 
already completed surveys were analyzed to develop stakeholder requirements, upon 
which functional analysis was performed using the Integration Definition for Function 
Modeling (IDEFO) method developed in CORE® software suite and applied the 
Department of Defense Architecture Framework (DoDAF) to develop the system 
architecture. An Analysis of Alternatives (AoA) was performed and development costs 
were estimated. Planning for solution implementation, integration and verification and 
validation were completed and are provided in a section listing recommendations. The 
conclusions made in this report are a direct result of the team’s education and experiences 
supporting the United States Navy (USN) and its Sailors, the research and analysis of 
customers and their needs, and aligns with the Chief of Naval Operations (CNO) Navy 
Distance Support Policy, which states that Distance Support is to be the “Fleet’s principal 
web-based readiness enabler, facilitating timely technical assistance, knowledge and 
education tools, and logistic support” (CNO 2007, 1). 

The requirements of homeland defense, national security, and the war on 
terrorism, as outlined in the National Strategy for Homeland Security dated July 2002, 
have made a Navy ship’s mission more critical than ever (U.S. Department of Homeland 
Security 2002). When equipment fails there is little time to wait for engineers or 
technicians to fly to the deployed ship to help resolve the problem, and in today’s current 
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fiscal climate, there is a strong pressure for In Service Engineering Agents (ISEA), which 
is one of NSWC PHD’s main responsibilities, to reduce costs. As an ISEA, NSWC PHD 
provides support through installation, certification and training of Sailors to operate and 
maintain surface ship combat systems and weapon systems already installed aboard ships. 
In a memorandum from the Commander of Naval Sea Systems Command (NAVSEA) on 
promoting efficient spending, all agencies are directed to take more aggressive actions to 
perform mission critical functions in the most efficient and cost effective manner (Vice 
Admiral (VADM) McCoy 2012). Functional areas, such as the use of government funds 
for travel, are directly affected and as a result, to maintain current levels of support while 
complying with a reduction of travel, it is imperative that effective Distance Support tools 
are offered to augment the support of those engineers and to provide the best possible 
level of support to the USN. Distance Support is defined by the CNO as “a Navy 
Enterprise effort that combines people, processes, and technology into a collaborative 
infrastructure without regard to geographic location” (CNO 2007, 2-1). Specifically for 
NSWC PHD, Distance Support is the technical help provided remotely to USN ships in 
all areas of operation and maintenance for warfare systems. 

Through the development, utilization, and delivery of leading-edge Distance 
Support technology to Sailors at sea, the engineers, logisticians, and technicians of 
NSWC PHD are working to help USN ships return to operational readiness twenty four 
hours a day, seven days a week without having to leave their positions. To NSWC PHD, 
Distance Support is important for the following reasons: 

• Reduced-manned ships, such as the Littoral Combat Ship (LCS) can 
equate to a smaller skill set of maintenance expertise 

• Increasing complexity of systems due to technological advancements, 
integration of emergent capabilities, and foreign combat system elements 
makes support more complicated 

• Pressures to reduce Total Ownership Costs (TOC) affect the amount spent 
on supportability. 
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Current Distance Support solutions performed at NSWC PHD include remote 
monitoring, prognostics and knowledge management. Remote monitoring utilizes 
satellite links to evaluate system operation aboard ships. Prognostics is done when data 
from shipboard tests is sent to NSWC PHD and examined for warning indications and 
trends that can lead to the discovery of these failed parts. Knowledge management is 
when NSWC PHD releases advisories, workarounds and heuristics of trouble calls to be 
stored and accessed by others. Although these methods are sound, they are often slow and 
ineffective. Numerous Distance Support tools exist; however, they were independently 
developed by each naval system. These tools each have their own unique set of 
requirements and capabilities and therefore function independently. These tools can be 
consolidated and/or integrated to more effectively provide the USN with a more capable 
Distance Support infrastructure. In addition, Distance Support activities are often not 
retained for knowledge retention and reutilization. Knowledge that is captured is difficult 
to access and utilize in a timely manner. Better tools need to be developed to allow 
knowledge to be captured and made ready for use when needed to help improve Distance 
Support and ultimately fleet readiness. For this capstone project, the team focused on 
determining what methods and tools were needed to allow Distance Support knowledge 
and experience to be captured and accessed efficiently. 

The team initially performed limited benchmarking, which is a process of 
investigating and discovering how others perform and/or provide particular functions and 
products of interest. For this project, the team researched how other organizations 
conduct Distance Support, whether or not they have experienced similar problems, and 
how they determine if Distance Support methods are successful. It was found that 
because of USN mission requirements, system failures cannot be tolerated for prolonged 
periods, which means the operators are more concerned about their present status, not in 
creating a holistic Distance Support system. 

This need to provide immediate support has created an environment where the 
reaction of technical support responders is to focus on near term or real time solutions 
because their primary concern is for ships in harm’s way, needing fully operational 
systems to avoid compromising their mission and loss of life. The result is a need for a 
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perpetually running system with the highest possible operational availability and lowest 
possible total downtime. While deployed, there are no spare ships to support a critical 
mission like there are spare tanks on the ground for the Army or aircraft in the hangar for 
the Air Force. During initial research and discussions, it was learned that the Navy 
already possesses numerous data collection and knowledge capturing tools and databases, 
such as modernization planning databases, casualty reporting databases, and specific 
system technical assist forms. Based on stakeholder feedback, the collective execution of 
Distance Support was unsatisfactory. 

A. PROBLEM STATEMENT 

In a 2010 Aegis Weapon System (AWS)/SPY Radar Readiness Report, the 
Deputy Commander of Surface Warfare (SEA 21) Rear Admiral James McManamon 
noted that “A decline in Sailors ability to operate, maintain, and sustain (combat systems) 
necessitates the need to optimize Distance Support from fleet field support activities to 
meet current and future fleet readiness demands.” As new surface ship programs emerge, 
the complexity of combat systems has increased. In recent years, the Navy has identified 
reducing manning levels as a key approach to reduce the fleet’s operational costs. In a 
2011 report detailing a review panel analysis of surface force readiness, it was noted that 
the Navy’s decision to reduce manning dropped the fleet’s availability levels to below the 
levels required to support material readiness requirements (Balisle 2011). With decreased 
manning, and the problem of inadequate Distance Support, problems with fleet readiness 
compound: reduced manning and inefficient Distance Support results in reduced fleet 
readiness, increases shore activity and Subject Matter Expert (SME) manpower 
requirements, decreases fleet independence, decreases efficiencies, and increases TOC. 

As has been previously noted, current NSWC PHD Distance Support systems are 
often slow and ineffective, with each trouble call being handled on an ad hoc basis and 
relying heavily on the servicing engineer’s personal experience. The solutions provided 
are not often captured for knowledge retention and reutilization and are not available as a 
self-help tool for the USN fleet as most responders and operators are more concerned 
with their present status rather than the health of the holistic Distance Support system. 


4 



Current tools used by the NSWC PHD SMEs to obtain and analyze system performance 
metrics are manually intensive, where operators must manually record and provide all 
performance metrics to the SMEs, and are thus limited in capability. As a result, 
engineering and supportability issues are not addressed in a timely manner and NSWC 
PHD SMEs are reacting to problems after they occur rather than being proactive to try 
and prevent problems. Furthermore, establishing relationships between similar problems 
continues to be a challenge as there is no systematic method to capture and maintain 
corporate knowledge of system issues found by the SMEs. A user-friendly efficient tool 
does not exist that captures knowledge through multiple available data sources for 
maintenance, performance and logistics that could be utilized in a timely manner to make 
Distance Support a more responsive and effective product. 

The CNO defines Distance Support as “a Navy Enterprise effort that combines 
people, processes, and technology into a collaborative infrastructure without regard to 
geographic location... [and] Distance Support projects reactive, proactive, and predictive 
support to Sailors across functional areas in order to achieve the right readiness at the 
right time, at the right cost” (CNO 2007, 2). The CNSF categorizes Distance Support by 
the following four functional areas: 

• Logistics 

• Maintenance and Modernization 

• Manpower, Personnel, Training and Education (MPT&E) 

• War fighting. 

In addition, each of these four categories has various sub-functions and unique processes. 
The magnitude and volume of fleet Distance Support activities that occur across these 
functional areas is enormous. The chart in Figure 1 describes some of the overall 
activities that are currently involved in providing Distance Support to the fleet. 
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In the far left of Figure 1, the fleet customer’s roles and needs are captured, in the list of 
requirements that are needed to conduct their mission. These requirements feed into the 
primary functions that ship’s personnel perform, which include maintenance, logistics, 
training, personnel and mission readiness. “Shore Support,” is the infrastructure that 
possesses the knowledge and capabilities that the fleet needs to support their mission. 
Between the fleet and shore support is the transport system that passes information and 
resources to and from the ship. As the diagram shows, Distance Support covers many 
functions and is quite complex. 

The team soon realized that a capstone project that improves fleet Distance 
Support across all four functional areas was beyond their ability, given the limited 
resources and time constraints to complete the project. The team agreed that the project 
had to be scoped to a manageable level, so it was re-focused to the Distance Support 
areas that NSWC PHD currently supports. NSWC PHD is primarily involved in limited 
aspects of logistics, maintenance, and modernization of combat systems installed on 
surface ships. Since most of the team’s work is related to maintenance, the team limited 
the scope of the research effort to maintenance functions. NSWC PHD’s capabilities 
include both remote systems monitoring and technical assistance. Both services are 
provided in real time, near real time, and on a periodic basis. In 2011, NSWC PHD 
promulgated a Fleet Support Guidance document, where remote monitoring was defined 
as “the automated collection of the minimum required data provides the greatest 
opportunity to ensure the fleet is ready for war” and technical assistance was described as 
an act that “may take various forms of two way contact including telephone, e-mail, web 
‘chat’, streaming video, etc.” 

In an effort to limit the scope of the project and increase chances for success, the 
team solicited input from NSWC PHD stakeholders. Stakeholders informed the team that 
they wanted the fleet’s ability to help itself improved and to improve capturing technical 
responses to technical assistances. This guided the team’s focus to developing a solution 
to aggregate data from numerous existing Distance Support sources and export data to the 
fleet to promote self-help and facilitate trend/failure analysis opportunities. Figure 2 
shows how data will flow to and from the aggregation tool. 
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Figure 2. Distance Support Process Focus Area 


After multiple iterations from discussions with advisors and stakeholders, the 
team developed the following problem statement to more completely capture the issue at 
hand. 


In recent years, the Navy’s decision to reduce manning and training with 
the increased complexity of combat systems as new programs emerge 
have led to a decline in Sailors’ ability to operate, maintain, and sustain 
combat systems to the levels required to meet mission readiness 
requirements (Balisle 2011). Numerous Distance Support tools currently 
used to respond to USN fleet combat system issues are often slow and 
ineffective. The eventual technical solutions are often not captured for 
knowledge retention and reutilization, nor are they available as a self-help 
tool for the war-fighters. Knowledge data that is captured is difficult to 
access and utilize in a timely manner. In addition, current Distance 
Support tools used by SMEs to obtain and analyze system performance 
metrics are manually intensive and limited in capability. 

This problem statement was derived based on two previous Distance Support studies that 

concluded that Distance Support is often slow and ineffective. These studies are not 
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releasable to the general public and were obtained from NSWC PHD sponsors. The first 
study was conducted by the AWS/SPY Radar Readiness Task Force in October of 2009. 
The Task Force performed an intensive review of all aspects regarding AWS/SPY to 
determine the factors that affect readiness for these two key warfare systems of the USN 
Fleet. The results and recommendations clearly pointed to these factors negatively 
affecting readiness. Some of the key issues identified are as follows: 

• Manpower reductions and a lack of necessary experience in operators 

• Inadequate shore-based training for the operators prior to deployment 

• Electronic versions of system drawings are being supplied to ships to save 
expense, but they are difficult to use in troubleshooting 

• Spare parts are not available on-board; requisitions have to be filled from 
other locations 

• Uncertainty of who to contact for Distance Support and on-site technical 
support and inefficiencies when support is provided 

• Auxiliary equipment support test and maintenance is frequently 
unavailable 

• Preventative maintenance is not emphasized 

• Fewer periodic ship assessments for the systems are performed than 
recommended 

• Distance Support is not used as often as it should 

• System performance monitoring and data collection is not being 
adequately done to determine readiness 

• There is not a consistent method to document issues (2010 AWS/SPY 
Radar Readiness Report) 

The second study used was the Distance Support Capability Based Assessment 
(CBA), which was conducted under the authority of Deputy Commander, United States 
Fleet Forces Command (USFFC) as part of a Distance Support Functional Analysis 
performed in 2010. The Distance Support CBA produced an integrated Distance Support 
capability proposal following the Joint Doctrine, Organization, Training, Materiel, 
Leadership and Education, Personnel and Facilities (DOTMLPF) and policy solutions. 
The CBA fulfilled the analysis portion of the Joint Capabilities Integration and 
Development System (JCIDS). It defined Distance Support capability needs, capability 
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gaps, capability excesses, and approaches to provide those capabilities within a specified 
functional or operational area. The Distance Support CBA has identified several areas 
that need to be improved. Those that directly apply to this capstone project are 
summarized as follows: 

• Knowledge Management-Distance Support needs to be focused on 
enabling information sharing and providing remote support for 
maintenance and logistics. If effective, the burden on the shore-based 
infrastructure will be lessened. 

• Collaborative Environment-Distance Support needs to utilize 

collaboration to provide timely technical responses, predict future material 
concerns and to enable the war fighter to employ proactive measures. This 
construct will improve Operational Availability (Ao), lower TOC and 
allow Sailors to gain more technical knowledge and skills. 

• Optimized, Reduced, Minimal and Multi-Crew Shipboard Manning 
(Formerly identified as ‘Minimal Shipboard Manning’)-New ship 
programs, such as LCS, are delivering ships based on the assumption that 
the ships can be staffed minimally and leverage off of improved Distance 
Support. Efficiency of technical troubleshooting is the key to allow the 
ship’s force to accomplish their diverse tasking. 

The results from both the SPY/Aegis Task Force and the Distance Support CBA 
drove the team towards developing a solution that will improve Distance Support 
effectively and increase fleet self-sufficiency. From the initial problem statement, project 
sponsors believed that numerous Distance Support tools exist but need to be consolidated 
and/or integrated more effectively. The key problem, as previously stated, is that 
Distance Support activities are often not captured for knowledge retention and 
reutilization and the knowledge that is captured is difficult to access and utilize in a 
timely manner. It is this particular problem that this capstone research seeks to address. 
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B. RESEARCH QUESTIONS 

The following research questions were used by the team to guide their research: 

• Why is improving the Navy’s Distance Support system important or 
necessary? 

• How do others conduct Distance Support and are they effective? 

• How do the stakeholders define an effective and affordable Distance 
Support system? 

• How can the existing Distance Support system be improved or modified to 
increase fleet readiness and reduce TOC? 

C. PROJECT ASSUMPTIONS AND CONSTRAINTS 

The analyses conducted and discussed in this report were based on the following 
assumptions: 

• Demand for Distance Support will increase or remain constant 

• Regional Maintenance Center (RMCs), who are on the waterfront and the 
ship’s first line of support on shore, and/or ISEA technical expertise, will 
be available for the foreseeable future 

• RMCs/ISEAs are committed to Distance Support knowledge capturing 
and reutilization. For Distance Support to be a helpful and useful tool, 
buy-in from all stakeholders must occur 

• The fleet and the shore support activities (to include the RMCs and 
ISEAs) will actively participate in improving Distance Support 

• Access to existing Navy data capturing and knowledge retention databases 
will be permitted. (Reusing existing data is critical to avoid having to 
create duplicate infrastructure and resources for capturing Distance 
Support experiences and knowledge) 

• Information contained within existing knowledge retention databases is 
sufficient for improving fleet self-help and performing data analysis. 
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Essentially, the assumptions made by the team were that the fleet would always need 
remote technical help and the USN Activities that are charged with technical support will 
continue to do so. Secure connection via the Web to the technical agents is also required. 

D. DESIGN TEAM STRUCTURE 

The capstone team consisted of eight distance-learning students. The team was 
co-located at Port Hueneme, California, except for one satellite employee located in San 
Diego, California. The team was diverse and included a mix of senior and junior 
engineers from electrical, electronics and computer engineering backgrounds. Due to 
travel commitments and the fact that one employee worked at a different location, various 
tools were utilized to maintain communication including web-based meeting platforms 
Defense Connect Online (DCO) and Elluminate, and the web-based fde sharing service 
Dropbox. In addition, weekly team meetings and class sessions were utilized for 
brainstorming sessions, discussing the status of projects and their progress, and preparing 
class materials and deliverables. 

To execute the project, the team utilized a matrix organization as depicted in 
Figure 3 that applied project management and SE disciplines across the various products 
required for a solution. The chart summarizes the team’s roles and responsibilities. 
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Figure 3. Design Team 
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The role of the Project Lead was to ensure the project was on schedule and 
meeting project objectives and requirements. Requirements engineering concerned the 
development, verification, and evaluation of all capstone project requirements. Cost 
Analysis included conducting the Business Cost Analysis (BCA) and Return on 
Investment (ROI). Architecture design included the development and design of the 
system architecture. This task translated stakeholder needs into system functional 
requirements and decomposed these requirements into functional architecture. Risk 
management covered the activities of conducting risk management, performing risk 
assessment, and providing risk mitigation. Personnel in charge of the AoA were tasked to 
lead the evaluation of alternative solutions. All team members were involved in the 
writing of the capstone report. The administrative members were responsible for taking 
notes during team meetings, keeping track of action items, and managing all other 
administrative needs that may develop during the life of the project. 

E. STAKEHOLDERS AND PROJECT SPONSORS 

A list of stakeholders and their primary concerns in regard to this project is given 
in Table 1. Based upon the problem definition and research into the problem domain, the 
team selected seven primary stakeholders to focus on to ensure their needs were 
adequately addressed. The project was principally focused on improving fleet readiness; 
therefore the most important stakeholder was the fleet itself, as they are the ultimate users 
and beneficiaries. 
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Stakeholder 

Primary Concern 

Fleet 

Improve fleet readiness, reduce Total 

Ownership Costs (TOC) 

Waterfront Activities 

Lack of adequate Distance Support capabilities, 
capture knowledge 

USN Type Commander (TYCOM) 

Improve fleet readiness, Distance Support 
effectiveness, system performance metrics 

Naval Sea Systems Command 
(NAVSEA) 

Lack of adequate Distance Support capabilities, 
reduce Life Cycle Cost (LCC), system 
performance metrics, failure trends 

Naval Surface Warfare Center, Port 
Hueneme Division (NSWC PHD) 

Improve fleet readiness, lack of adequate 

Distance Support capabilities, capture 
knowledge, and reduce LCC/TOC 

Program Executive Office (PEO) 

Improve Distance Support and reduce TOC, 
failure trends, acquisition impacts 

Office of the Chief of Naval 
Operations (OPNAV) 

Improve fleet readiness and reduce TOC 


Table 1. Stakeholders 


While effective Distance Support can improve the work of many different 
stakeholders, there are many priorities shared by all. The primary concern of the fleet was 
to minimize equipment down time, which was also a concern shared by all stakeholders. 
An additional concern important to the fleet (and all stakeholders) was the improvement 
of equipment reliability and the reduction of TOC. In a budget constrained environment, 
reducing TOC was extremely important for ensuring an affordable Navy for the future. 

All of the project sponsors are from NSWC PHD and are listed in Table 2. NSWC 
PHD, as the ISEA for most of the Navy’s surface weapon systems, has the unique ability 
to influence and address stakeholder concerns. Knowledge capturing and knowledge 
reutilization are key components to enabling NSWC PHD to improve component/system 
reliability and to provide faster, more thorough Distance Support to the fleet, all of which 
improves fleet readiness and while reducing TOC. 
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Sponsor 

Title 

Mr. Timothy Troske 

Technical Director 

CAPT Theodore Olson, USN 

Office of Logistics (OOL), Deputy Commander 

Mr. Fabio Vitale 

OOL, Director 

CAPT Scott Davis, USN 

Chief Engineer (CHENG), Office of Engineering 
Technology (OET) 

Mr. Dave Scheid 

OET, Chief Innovations Officer 

Mr. David Williams 

OET, Distance Support Advocate 

Ms. Coralyn Akers 

Fleet Liaison 

Mr. John Lester 

Systems Engineering (SE)-Air Dominance Department 
Lead 

Mr. Noel Camanag 

SE-Land Attack Department Lead 

Mr. James Childs 

SE-Ship Defense and Expeditionary Warfare 
Department Lead 

Table 2. 

NSWC PHD Project Sponsors 


F. SYSTEMS ENGINEERING PROCESS 

A tailored SE process was used to reflect the uniqueness of the project. The team 
adopted the new 2009 DoD SE Model as shown in Figure 4, as a framework for the 
project SE process due to its standard applicability to SE projects (Defense Acquisition 
University (DAU) 2011). The 2009 DoD SE Model consists of two major processes: 1) 
the technical management process, which steers system development to meet project or 
phase objectives, and 2) the technical processes, which are depicted in a V-shaped pattern 
to portray the “top-down” design that occurs as requirements are allocated from the 
system to lower-level elements. The V-shaped model also shows the “bottom-up” 
realization, from the lowest level components to higher assemblies to achieve the 
complete system. The technical processes are applied across the life cycle of a system 
and at different levels in the system hierarchy to develop the system (DAU 2011). 
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Figure 4. 2009 DoD System Engineering Model (From DAU 2011) 

The team used the tailored SE process as illustrated in Figure 5 for activities 
in the development of the capstone project. This figure reflects the project activity 
hierarchy that was pursued as the team progressed through the SE process. The first 
step was to define the stakeholder needs. This step was accomplished by reviewing 
past studies and already completed surveys provided by NSWC PHD project 
sponsors, categorizing the results, and conducting a needs analysis. The results of the 
needs analysis were then used for the requirements analysis. After completing the 
requirements analysis, the system architecture was designed and modeled. A 
preferred solution that adequately satisfies stakeholder requirements was then 
recommended for system implementation. 
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Figure 5. SE Process to Project Activities (After DAU 2011) 

Figure 6 shows the SE process used for mapping stakeholder needs to alternative 
solutions. The first step was to map needs to requirements, followed secondly by 
requirements to functions, and thirdly functions to components. The mapping process not 
only allowed alternative solutions to be compared, it also provided traceability back to 
the requirements. The Vitech CORE® modeling tool was used to capture, track, and 
produce the SE architecture artifacts which will be discussed in more detail later in the 
report. Through CORE®, the requirements were mapped into a hierarchy and then 
allocated to system functions. These functions were then tied to forms or components for 
the architecture. 
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Figure 6. Requirements to Components Mapping Process 
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G. SUMMARY 


The project development methodology was to: 1) apply SE techniques to clearly 
define the problem, 2) prioritize stakeholder requirements, 3) perform a functional 
analysis, 4) research and compare possible solutions, and 5) develop a conclusion and 
recommendation. In addition, the project focused on finding a solution to determine what 
methods and tools were needed to allow Distance Support knowledge and experience to 
be captured and utilized to help improve Distance Support and ultimately fleet readiness. 
The stakeholder needs focused on developing a solution that would aggregate data from 
numerous existing Distance Support sources, export data to the fleet to promote self-help, 
and export data to help facilitate trend and failure analysis opportunities. Finally, the 
project scope focused on improving Distance Support knowledge capturing and 
reutilization as it applies to NSWC PHD. Subsequent chapters of this report will discuss 
in detail these SE techniques in turn and outline how the team came to their conclusion. 
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II. DEFINING STAKEHOLDER NEEDS 


The first step of the SE process was to define stakeholder needs. This was an 
important first step to developing a conceptual design of the system that would provide 
the stakeholders with a preferred solution. “Having defined the problem completely and 
thoroughly, a needs analysis should be performed with the objective of translating a 
broadly defined ‘want’ into a more specific system-level requirement” (Blanchard and 
Fabrycky 2011, 58). 

A. DERIVING STAKEHOLDER NEEDS 

The first step taken after developing the initial problem statement was to 
determine the stakeholder needs. To help with this, the team met with key NSWC PHD 
sponsors, Dave Scheid and David Williams, and solicited their guidance on how best to 
approach this task. In addition to providing guidance, the sponsors also provided past 
Distance Support studies that were previously conducted. 

Two of the studies utilized by the team were summarized in Chapter I. In 
addition, the team was also provided survey results that were originally used to develop 
the LCS Distance Support philosophy. The survey results are not releasable to the general 
public. In summary, this report details the methodology, findings, and recommendations 
following three days of Culture Mapping Sessions held in Naval Base San Diego and at 
NSWC PHD in January of 2012. Culture mapping methodology included several small 
group sessions which encouraged anecdotes on the current state of Distance Support and 
then were “mapped” to determine a more complete understanding of its nature. These 
sessions were also conducted to understand the Distance Support processes and functions 
across the fleet and discern the challenges to Distance Support that LCS may present as a 
unique mission platform. To NSWC PHD sponsors, these results were very important 
because the LCS shipboard manning is expected to be significantly lower than traditional 
war ships, which means that LCS ships will be more dependent on Distance Support than 
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ever before. One of the most important findings from the culture mapping reports was 
learning that to be useful, a tool must be simple to operate and be quick to provide help. 

The stakeholder needs were derived from the LCS Culture Mapping Sessions and 
the past Distance Support studies. The stakeholder needs were then organized and re¬ 
written in terms of requirements. Requirements are discussed in more detail later in the 
report. 

B. NEEDS ANALYSIS 

By performing a thorough stakeholder needs analysis, the team determined that 
NSWC PHD needed to improve Distance Support data aggregation and knowledge 
reutilization in order to provide more effective Distance Support capability to the fleet. In 
addition, improved data aggregation enables NSWC PHD to perform more effective trend 
analysis to improve equipment reliability, utilizing existing shore support resources and 
processes. 

When a failure occurs with a shipboard system, Sailors normally engage in 
troubleshooting efforts to isolate the failed component based on their own experience. 
Sailors are usually motivated to correct the failure as quickly as possible and if this effort 
is prolonged, the Sailor will look for assistance from others. The first priority is to 
exhaust the resources available on the ship and once that occurs, the Sailor will pursue 
assistance from ashore. The typical process is to contact the local RMC and if those 
resources are not readily available then they often contact the ISEA. The last resort is 
usually to contact the Original Equipment Manufacturer (OEM). To summarize, the 
current process is usually time consuming and significantly prolongs system down time. 

In today’s environment where ships are a limited resource, Sailors have more 
collateral duties and have very little time for combat system maintenance. To avoid 
lengthy troubleshooting sessions, Sailors often prefer someone telling them what 
component to replace and how to replace it. An analogy would be that the “check engine” 
light in a car goes on so the owner takes the car to the dealer for a diagnosis. The dealer 
quickly determines which parts have failed. The owner can then buy the parts and install 
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them or have the dealer install them. In that scenario, the problem gets fixed with the 
least amount of the car owner’s time consumed. Thus, the requirements for help can be 
colloquially summarized as follows: 

• Determine what’s broken with the system (i.e., what failed or what’s not 
working right) 

• Determine what parts need to be ordered and from where (in the most 
expeditious way) 

• Determine how to replace the parts 

• Determine what to do with the old parts. 

Using the analogy above and feedback from stakeholders, the following general 
statements seem to capture some of the most important self-help requirements for the 
Navy. Operators need: 

• Help with operation and maintenance 

• Quick access to the right information or resources (including people) 

• Useful and effective information or assistance 

• Information that is easy to understand and follow information 

• Help that is immediate or information regarding who to contact for more 
help. 

According to the stakeholders, the most effective Distance Support system would 
include the ability to conduct prognostics to predict failures in advance and replace 
defective components before they fail; this would mean that equipment would be 
replaced at a more convenient time than would be the case if equipment was replaced 
because of failure or at an unanticipated time. In the absence of prognostic capability, 
which has not yet fully matured, the most effective Distance Support system would 
emulate having fully knowledgeable technical experts and complete parts support on 
board a ship so that when a combat system experiences a failure, the root cause can be 
determined without delay and the failure corrected immediately. In regards to 
maintenance, minimizing down time is the key element of achieving high Ao and the 
highest state of fleet readiness. Any delays in replacing failed components results in 
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longer down times. As discussed previously, in today’s Navy not all parts are available 
on board and the availability of technical experts is limited. The most knowledgeable 
technical experts are not shipboard and reside on shore at various organizations. These 
organizations include the RMCs, the ISEAs, and the OEMs. If it were possible to place a 
SME on every ship, the need for Distance Support would be eliminated. Since these 
resources are mostly civil servants and private parties, it is not possible to position these 
resources on a Navy war ship, especially in combat. Technical experts consist of trained 
professionals with the most knowledge, skills, and abilities; the expertise of such a 
technical expert is difficult to have shipboard. The turnover frequency of active duty 
military personnel alone prevents sufficient retention of fully trained individuals. 
Therefore, the goal of an effective Distance Support system are to provide immediate 
access to the SMEs, share as much system fault information with that SME, and provide 
the ship with immediate access to the knowledge that the technical experts possess 
without having to contact or position the technical expert on site. 

From the stakeholder needs analysis, the ideal solution would meet the following 
criteria for knowledge and technical information: 

• Easily accessible 

• High Quality information (accurate, useful, reliable, and complete) 

• Data sorted by its age (i.e., providing most recent information) 

• Well organized data 

• Information displayed and/or reported when needed. 

Past Distance Support surveys and studies showed that Sailors usually avoid using 
any process or tool that does not meet the above criteria. Thus, providing Sailors 
immediate access to technical information that meets the above criteria should improve 
self-help. This change would reduce the need to contact SMEs ashore. 

Ship-to-shore access to technical information currently exists but is often slow or 
difficult to access and utilize. The primary vehicles for accessing technical information 
include websites, electronic media like Compact Disks (CD), and e-mail. E-mail is 
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currently the most convenient method, but Sailors often experience delays because of not 
knowing who to contact, different time zones, and SME availability. Although e-mail is 
often slow, it is usually effective at getting help to the ships, eventually. Ships have 
bandwidth limitations that often prevent Sailors from accessing and searching the 
numerous websites that are available, especially while deployed. In addition, many 
Sailors are often not aware of the websites that are available, including the NSWC PHD 
Sailor to Engineer (S2E) website. Numerous websites exist, but contain limited 
information and are usually only updated as a need arises, websites are convenient but 
rarely meet the required attributes for Distance Support, which are easily accessible, high 
quality information, most recent data, and well organized. Thus, Sailors rarely prefer to 
utilize websites because they fail to meet the minimum Distance Support criteria 
provided above. 

Technical and recorded information that resides on unique databases and servers 
is also difficult for Sailors to access. Typically, to have access, a user is required to obtain 
permission to use the information contained in the database. Once permission is provided, 
finding useful information can be extremely difficult and time consuming. On the other 
hand, many databases are routinely updated by the host organization and usually contain 
the most recent historical information. In addition to technical information, information 
related to maintenance performed by others and past Distance Support experiences is 
often captured in these databases. SMEs also rely on this technical and historical 
information for conducting technical assistance. The ability to extract and display 
information, automatically when needed, could significantly increase self-help 
capabilities. 

C. OPERATIONAL CONCEPT DEFINITION 

The team defined a system that would answer all the needs described by the 
stakeholders and referred to it as the Data Aggregation System (DAS). The operational 
concept of the DAS was to aggregate, and integrate engineering and supportability 
information from internal and external sources and to capture SMEs knowledge to 
improve today’s and tomorrow’s fleet readiness through Distance Support capabilities. 
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The system will enhance the effectiveness and efficiency of near real-time data 
management and utilization by providing benefits in the following ways: 

• Providing maintenance information to enable fleet self help 

• Providing insight to help predict potential problems before they occur by 
utilizing Key Performance Indicator (KPI) “triggers” to help focus SMEs 
on the pertinent issues for their systems 

• Addressing engineering and supportability issues quickly by automating 
data collection/aggregation from a variety of available sources 

• Assisting sponsors and/or customers in prioritizing requirements within 
the budget cycle 

• Managing engineering expertise and knowledge effectively 

• Providing accurate and repeatable results through standardization of fault 
diagnostics and repair 

• Providing the ability to efficiently display baseline or combat system 
cumulative reporting across the enterprise in support of organizational, 
programmatic, or individual needs 

• Providing timely and accurate information to the SME for fleet technical 
assistance via Distance Support 

• Providing the ability to produce special reports quickly and more cost 
effectively 

• Capturing corporate knowledge from the SMEs, situations, and processes 
continuously and make available for training and future reference/analysis 

• Maintaining historical records and related corporate knowledge that is 
easily retrieved by any user. 

The diagram shown in Figure 7 describes the concept operation of the DAS where 
multiple data sources are collected either from the ships or from various fleet support 
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agencies. After the data is collected through a network interface, the system will then 
process and analyze the data to generate multiple products that are categorized as 
follows: 

• Performance Health Trigger, which is a key parameter with a threshold 
associated to it directly related to the performance of a system 

• Corrective Maintenance Solutions are considered as equipment 
troubleshooting tips provided by the SMEs, list of common equipment 
failure items and common corrective actions, updated troubleshooting 
procedures and maintenance work packages, part list, and many more 
products that can be used for self-help corrective maintenance 

• Predictive Analysis and Modeling, or forecasting future states and issues 
of the system based on historical data 

• Operational Data Analysis; analysis of ship’s system performance based 
on different mission area 

• Statistic Modeling, results from system testing and Reliability, 
Maintainability, and Availability (RMA) data collected over time can be 
used to create statistic model for future trending and predictive analysis 

• Data Validation; ship’s system performance and system configuration data 
will be collected, measured and validated with specification requirements 
for accuracy and effectiveness. 

The arrows in the center of Figure 7 that are pointing to the top of the diagram 
reflect information and knowledge being reused and shared with both the fleet and shore 
support organizations. The data aggregation occurring in the middle is the primary focus 
of this capstone project. 
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Figure 7. Data Aggregation System Operational Concept 


1. DAS Users 


In the context of operation, the “user” is defined as anyone who utilizes the DAS 
to analyze data or obtain information. A user can be a SME of a particular system, fleet 
customer, or sponsor who has the need to see the system life cycle data. Additional 
details on how each of these users will utilize the Data Aggregation are described in the 
following paragraphs. 


a. SME 

Equipment, software, and systems engineers, as well as supportability and 
financial personnel will use the DAS as a resource to conduct engineering and 
supportability investigations. The DAS will allow the SME to review multiple data 
sources, such as technical assistance data generated by the Command Issues Management 
(CIM), remote system diagnostic and assessment reports resulted from Operational 
Readiness Test System Tech Assist Remote Support (ORTSTARS), testing Maintenance 
and Material Management (3M) data which contains RMA data imported from the 
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Material Readiness Database (MRDB), supply data collected from the Naval Supply 
Systems Command (NAVSUP) database, and so forth. These users would utilize the data 
to conduct root cause analysis and develop a possible solution to issues. 

b. Fleet Customer 

The USN fleet, RMC personnel, USFFC, Type Commanders (TYCOMs), 
and Class Squadrons (CLASSRON) will use the DAS as a data source which will provide 
pertinent data needed to assist with fleet responses to system and equipment maintenance 
and performance issues. These issues may include common questions and answers 
pertaining to equipment corrective maintenance, troubleshooting procedures, metrics, 
information on issues that the SME has analyzed, fleet issues addressed previously, or 
other concerns investigated by the ISEA. 

c. Program Sponsors 

Sponsors such as NAVSEA, Program Executive Office, Integrated 
Warfare Systems (PEO IWS), Program Executive Office, Ships (PEO SHIPS), Program 
Manager, Sea Navy Theater Wide Program Office (PMS 452), USN Missile Defense 
Agency (MDA) and NSWC PHD will use the DAS information and results of 
engineering and supportability investigations to assist them in making high-level 
decisions based on historical data, trends, fleet usage, and emergent issues. 

2. DAS Data 

The DAS will access the data from multiple sources through a network interface 
connected through the Navy’s existing network infrastructure. Based on the team’s 
research, the databases discussed in the following subsections were identified as 
prominent data sources that will be accessed and processed by the DAS. These databases 
contain a significant amount of information and most are routinely updated with new 
information as it becomes available. Most of this information is currently used by ISEAs, 
shore support maintenance personnel and the supply system to track system 
configurations, system performance, maintenance actions, and to improve system 
reliability. Shipboard Sailors rarely possess or attempt to access the information 
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contained within these databases, primarily due to a lack of awareness of the databases’ 
existence or utility, difficultly accessing information, or the need to obtain permission. 
The information contained within these databases is extremely useful for sharing past 
Distance Support experiences and for identifying reliability improvement opportunities. 
In addition, much of the knowledge that SMEs possess is captured within these 
databases. The DAS will be a tool that will process this information in a way that satisfies 
the Distance Support criteria, improving the self-help capability. To satisfy the Distance 
Support criteria developed in this report, the data will have to be aggregated such that the 
information is readily accessible, high quality, and well organized. 

a. NA VSEA Logistics Center (NSLC) Maintenance and Material 
Management (3M) 

The 3M repository contains shipboard created deferred and non-deferred 
jobs, shore facility jobs created in support of ships, and information related to the 
planning of deferred maintenance. The repository also contains Intermediate Maintenance 
Activity job completion information and some public/private depot level completion data 
for off-ship maintenance. Supply transactions that associate supply demands to shipboard 
and non-shipboard issues are available within the new repository. Preventive 
Maintenance (PMS) completion information is also available. The database has been 
enhanced to include, metrics at the job level and a breakout of Selective Level Reporting 
information from in-stream narrative to fielded table information. 

DAS will obtain 3M data for two main reasons, which are to obtain ship 
and equipment configuration information and ship and equipment field maintenance 
information. This information is used to provide System Operational Effectiveness (SOE) 
metrics, which are Mean Time Between Failures (MTBF), cost, number of failures due to 
human factors, and so forth. 

b. Command Issues Management (CIM) 

CIM is an application which is being used to track all NSWC PHD fleet 
technical assistances, and other types of work, for instance program action items, trend 
analysis, system anomalies, engineering investigations, and so forth. DAS will obtain 
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CIM data to report the effectiveness of NSWC PHD’s support to the Fleet. Some 
examples of CIM metrics are: 1) Technical Assistances (TA) open greater than or equal 
to 90 days at the end of the month, 2) TA costs due to closed TAs open less than 90 days, 
and 3) TA productivity metrics for TAs closed less than 90 days. 

c. Test Observation Reports (TORs) 

The TORs database contains Test Observation Reports from Combat 
System Ship Qualification Trial (CSSQT) and other test events in which NSWC-PHD 
participates. DAS will obtain TOR data to report system Probability of No Human Error 
(Pp) metrics and Human System Integration (HSI) information as part of NSWC PHD’s 
Safety Effective and Affordable Review (SEAR) process. TOR HSI elements are as 
follows: 1) human factors, 2) personnel, 3) habitability, 4) manpower, 5) training, 6) 
survivability, and 7) environment, safety and occupational health. 

d. Engineering Information System (EIS) Problem Description 
Database (PDDB) 

The EIS PDDB contains engineering problem description reports for 
investigations in which NSWC-PHD participates. DAS will obtain EIS PDDB data to 
report open and closed engineering investigations on equipment. 

e. General Distribution Allowance Parts List (GDAPL) 

The Navy’s General Distribution Allowance Parts List (GDAPL) cross- 
references part numbers, National Stock Numbers (NSNs) and Commercial and 
Government Entity (CAGE) Codes to Allowance Part Lists (APLs). Obtained from the 
Navy Ships Parts Control Center (SPCC), this database shows top-down, bottom-up 
relationships between all parts in the system. GDAPL is a Microsoft® Windows based 
application; it contains a current drawdown of the Weapon Systems File for APLs and 
Allowance Equipment Lists (AELs) as of the date of extraction. The GDAPL is a 
quarterly issued item, and is distributed in October, January, April, and July. DAS will 
obtain GDAPL information to develop equipment configuration management tables that, 
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in turn, support SOE metrics. For more information on GDAPL, visit the website: 
http://www.navicp.navy.mil/05/caprod.htm. 


f. Material Readiness Database-Next Generation (MRDB-NG) 

MRDB-NG data is a consolidation of validated 3M, Casualty Report 
(CASREP), employment, cost, equipment identification code, and other information 
which is then used to generate overall equipment Ao, MTBF, Mean Time To Repair 
(MTTR), support indices, and other logistics and sparing indices at the system level. 
Equivalent indices and cost of replacement parts are also generated at the block and part 
level. DAS will obtain MRDB-NG information for equipment Ao metrics that, in turn, 
supports SOE metrics. 


g. Navy Data Environment -Afloat Master Planning System (NDE- 
AMPS) 

The Afloat Master Planning System (AMPS) provides data on major 
shipboard systems (Configurations) with a focus toward Battle Force interoperability. It 
also carries planning information about scheduled Installations, Alterations and 
Configuration Changes. DAS will obtain AMPS data for Strike Group configuration 
information that, in turn, supports SOE metrics grouping at the strike group level. For 
more information on NDE-AMPS, visit the website: https://www.nde.navy.mil/. 

h. Global Distance Support Center (GDSC) Remedy 

The GDSC Remedy is a virtual call center connecting Fleet and Industrial 
Supply Center (FISC) Norfolk and San Diego to process customer requests for 
information, products and services from the logistics system. DAS will obtain GDSC 
Remedy data to report to NSWC PHD the effectiveness of NSWC PHD’s support to the 
Fleet. Some examples of GDSC Remedy metrics are: 1) TAs open greater than or equal 
to 90 days at the end of the month, 2) TA costs due to TAs closed in less than 90 days, 
and 3) TA productivity metrics for TAs closed in less than 90 days. For more information 
on GDSC Remedy, visit the website: http://www.anchordesk.navy.mil/. 
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Diminishing Manufacturing Sources and Material Shortages 
(DMSMS) 


The Government-Industry Data Exchange Program (GIDEP) is a 
cooperative effort to exchange research, development, design, testing, acquisition, and 
logistics information among government and industry participants. DMSMS notices 
originate when a part manufacturer announces that a part or a production line will be 
discontinued. The majority of GIDEP DMSMS notices have been issued on piece parts, 
especially in the electronics area (primary microcircuits); however, DMSMS also occurs 
at the module, component, equipment, or other system indenture level. GIDEP is 
designated as the Department of Defense centralized database for managing and 
disseminating DMSMS information. The database contains data for not only parts 
manufactured in accordance with military or government specification but also 
commercial parts. DAS will obtain DMSMS data to identify Lowest Replaceable Units 
(LRUs) that are of concern to the ISEA because they are or will be obsolete. For more 
information on DMSMS, visit the website: http://www.gidep.org/. 

j. Federal Logistics Data (FEDLOG) Information Center 

FEDLOG can be used by engineering, technical research, provisioning, 
procurement/contracting, supply, cataloging, maintenance, distribution, storage, 
transportation, quality assurance and disposal personnel to retrieve management, 
part/reference number, supplier, commercial and government entity, freight, 
Interchangeability and Substitutability (I&S) and characteristics information recorded 
against NSNs. FEDLOG also provides service unique data for additional search 
capabilities. FEDLOG is published monthly on Compact Disk-Read Only Memory (CD- 
ROM) and Digital Video Disc (DVD) by the Defense Logistics Information Service 
(DLIS). DAS will obtain FEDLOG information to develop a National Item Identification 
Number (NUN) to CAGE and part number cross-reference table because LRUs may be 
referred to by part number by engineers and by NUN by logisticians. For more 
information on FEDLOG, visit the website: http://www.nslc.navsea.navy.miE. 
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k. Program Information System Mission Services (PRISMS) 

The PRISMS database contains the configuration data used by the Board 
of Inspection and Survey (INSURV) to conduct their inspections. DAS will use PRISMS 
information to support INSURV information-based products. 

/. Navy Data Environment (NDE) - Configuration Data Managers 
Database Open Architecture (CDMD-OA) 

The CDMD-OA tracks the status and maintenance of naval equipment and 
their related logistics items, such as drawings and manuals, on ships and naval activities 
around the world. The term “open architecture” is used to denote the fact that CDMD-OA 
is a client/server-based system, not dependent upon any vendor’s proprietary hardware or 
software; data may flow to and from CDMD-OA provided that open protocols are used. 
The status of a given piece of equipment on a ship determines what and how many spare 
parts will be stored on that ship for it, making this tracking extremely important in terms 
of cost, shipboard space and weight, and the operational availability of the ship. DAS will 
obtain CDMD-OA information for ship / equipment configuration information. For more 
information on NDE CDMD-OA, visit the website: https://www.nde.navy.mil/. 

m. Trouble Feedback Reports (TFBRs) 

The TFBRs database contains records of equipment malfunction events 
that occurred at the Aegis production test center and shipyard. TFBR information will be 
used for production and/or integration performance metrics that, in turn, support SOE 
metrics. 


n. Safety Hazard Alert Reports (SHARs) 

The SHARs database contains Safety Working Group investigation 
summaries for Aegis ships. SHAR data will be used to support safety metrics that, in 
turn, supports NSWC PHD’s SEAR process. 
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o. NDE-Navy Modernization (NDE-NM) 

NDE-NM is a database that tracks and maintains logistical data for 
modernizing ships in the Navy. NDE-NM stores engineering information, alteration 
information, automated tracking of materials usage and requirements, alteration 
scheduling and completion status and detailed shipyard scheduling. DAS will obtain 
NDE-NM information to identify ship availabilities, their duration, and when they 
occurred. This information is used to derive operating times that, in turn, supports SOE 
metrics. For more information on NDE-NM, visit the website: 
https://www.nde.navy.mil/. 

p. Visibility and Management of Operating and Support Costs 
(VAMOSC) 

The Navy VAMOSC management information system collects and reports 
USN and U.S. Marine Corps (USMC) historical weapon system Operating and Support 
(O&S) costs. VAMOSC provides the direct O&S costs of weapon systems, some linked 
indirect costs (e.g., ship depot overhead), and related non-cost information such as flying 
hour metrics, steaming hours, age of aircraft, and so forth. VAMOSC has recently added 
the military personnel database, which contains all active duty USN and USMC 
personnel costs and attributes data. DAS will obtain VAMOSC data to support 
affordability metrics that, in turn, supports NSWC PHD’s SEAR process. For more 
information on VAMOSC, visit the website: http://www.oscamtools.com/Vamosc.htm. 

q. Aegis Configuration Control and Engineering Status System 
(ACCESS) 

The ACCESS database contains data for ship / baseline configuration 
information and for alteration information. DAS will use ACCESS data to group ships by 
baseline and to determine if and when an alteration has been installed on a particular ship. 

r. Board of Inspection and Survey (INS UR V) 

The INSURV is tasked with conducting material inspections and surveys 
of ships and service craft and providing an assessment of the material readiness of these 
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vessels to Congress and Navy leadership. DAS will use INSURV material readiness 
information to support NSWC PHD’s SEAR process and INSURV results data analysis. 

s. Aegis Weapon System (A WSJ Part-to-Block 

AWS Part-to-Block is data from the OEM that lists AWS LRUs, the block 
in the reliability block diagram they belong to, the quantity of each in each block, the 
criticality of the part to the block and to AWS, and the minimum quantity of parts 
required to be operational within the block. 

t. Sailor To Engineer (S2E) 

S2E is a web-based portal hosted by NSWC PHD that provides Sailors the 
instant access to engineering and logistics experts at NSWC PHD and other NSWC 
commands. The S2E page is a source of information for solving problems and answering 
questions regarding combat/weapon systems, hull, mechanical, and electrical systems, or 
underway replenishment performance and maintenance. 

u. Aegis Combat System Reliability Maintainability Supportability 
(ACSRMS) 

The ACSRMS database is comprised mostly of database objects germane 
to the Aegis Combat System (ACS). ACSRMA includes data from the following 
databases: ACCESS, GDAPL, PDDB, SHARs, and TFBRs. Depending on the 
completeness of the data contained in ACSRMS, DAS may just obtain the data directly 
from ACSRMS instead of query the data from original sources. 

D. SUMMARY 

From the needs analysis, it was determined that the stakeholders needed a system 
that provides easily accessible data, high quality information, current data, well organized 
information, and information displayed and reported when needed. An operational 
concept diagram was developed to show, at a very high level, the operational 
relationships amongst users and the new proposed DAS. Chapter III discusses how these 
needs were mapped to system requirements, then to functions, as well as the AoA that 

was conducted to determine the best alternative that answers the stakeholder’s needs. 
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III. REQUIREMENTS ANALYSIS 


The second step in the SE process, after defining stakeholders’ needs, was to 
conduct the requirements analysis that identified the operational, functional, physical, and 
performance requirements (Blanchard and Fabrycky 2011). The requirements analysis 
process was necessary to translate the needs of the stakeholders into an operational 
scenario. This assisted with the development of the set of system operational 
requirements, the maintenance and support concepts, and the identification of Measures 
of Effectiveness (MOE) and Measures of Performance (MOP). These requirements and 
measures were then used to compare the operational suitability of alternatives so that the 
most effective solution was chosen based on a sound scientific process. 

A. DEFINING STAKEHOLDER REQUIREMENTS 

Requirements were used to determine the functional and physical characteristics 
for the integration and design considerations of the DAS. Figure 8 shows a simplified 
view of the requirements generation process as it relates to the other major SE tasks 
within this project. As the figure depicts, requirements drive system functions that in turn 
drive physical components considerations. An architecture framework is used to 
construct a solution that will bound and clarify requirements, functions, and physical 
components. As constraints or limitations are reached or discovered within each process, 
a feedback loop exists to initiate re-evaluation of that particular element. 



Figure 8. Requirements Mapping in SE Process 
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To identify requirements, the Distance Support capstone team analyzed a 
combination of inputs from the stakeholders, including past studies and already 
completed surveys conducted by NSWC PHD personnel in relation to Distance Support, 
which was discussed in detail in Chapters I and II. The team then compared the system 
requirements with the Distance Support policy and guidance published by SEA 21 to 
ensure all requirements met current Distance Support standards. From these inputs, the 
requirements for DAS were identified. A complete listing of these requirements can be 
found in Appendix A. 

B. REQUIREMENTS PARTITION 

Figure 9 shows the DAS requirements. The team used their past experiences with 
Navy standard formats for developing combat system requirement specifications to group 
the requirements into three different categories. The categories are defined as: 1) 
Characteristics, 2) Design and Construction, and 3) Component Level Requirements. The 
first category, Characteristics, is where the requirements are related to system capability 
and performance. The second category, Design and Construction, calls out the 
requirements associated with data accessibility: data collection, data formatting, the 
interface encountered by the user, and the aspects dealing with Information Assurance 
(IA) compliance. The third category, Component Level Requirements, identifies the 
requirements for the hardware and software. 
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Figure 9. Top Level Requirements 

1. Characteristic Requirements (R.1.0) 

The characteristic requirements as shown in Figure 10 define the requirements of 
the system based on its performance, physical characteristics, reliability, maintainability, 
as well as the environment conditions where the system will be operated. 


hier Characteristics 



Project: 


Distance Support Data Aggregation System 


Organization: 


December 26, 2012 


Figure 10. Characteristics Requirements 


39 




















































































a. Performance Requirements (R. 1.1) 

The performance requirements shown in Figure 11 address the 
requirements of the DAS based on the primary functions that must be executed in support 
of DAS’ mission. The requirements are measured in terms of accuracy, accessibility, 
quality, and timeliness. The performance requirements of the DAS are categorized and 
described as follows: 

(1) External Interface: The system shall be capable of 
interfacing with various other systems, databases, and data systems to collect and provide 
necessary data to perform all the functions. 

(2) Fleet Maintenance Support Data and Metrics: The system 
shall process, analyze, and provide data and metrics that will be used to support fleet 
maintenance. 

(3) Logistics Data: The system shall process, analyze, and 
provide logistics data in support of fleet maintenance and life cycle support. 

(4) Training Data: The system shall provide data that reflects 
fleet training discrepancies. 

(5) RMA Analysis Data: The system shall be able to process, 
analyze and provide RMA data with respect to combat system performance. 

(6) Reports: The system shall be designed to allow the user to 
generate, save, and print the reports to a file with the standard format such as Acrobat 
Portable Document Format (PDF) or Microsoft® Office products (i.e., Word or Excel) 
from the web pages where the data can be selected and filtered by user defined 
characteristics. 
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Distance Support Data Aggregation System 

Organization: 

NSWC PHD 

Date: 

December 26, 2012 




Figure 11. Performance Requirements 
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b. Physical Characteristics (R.1.2) 

This group of requirements was established to ensure the DAS will not 
exceed the physical capabilities of the host platform. Among these characteristics, the 
following are deemed most critical to a successful integration: human system integration, 
and physical size (dimensions). 

The physical characteristics requirements, as shown in Figure 12, were 
decomposed to the following listed requirements: 

(1) Human System Integration: The system shall be designed 
and tested to satisfy human engineering design requirements and standards included in 
but not limited to the latest version of DoD Design Criteria Standard Human Engineering, 
U.S. Army Aviation and Missile Command, MIL-STD-1472F, 1999. 

(2) Size: The physical size of the DAS shall conform to the lab 
space available at NSWC PHD. The major components that are selected for the system 
shall support rack mount installation. 



Figure 12. Physical Characteristics 
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c. Reliability (R.1.3) 

The reliability requirement establishes the minimum mean time between 
failures that the system must achieve in response to internal system failures (i.e., faults, 
component failures). The Key Performance Parameters (KPP) subsection, discussed later 
in this report, provides additional information, including the threshold value that must be 
achieved. 


d. Maintainability (R.1.4) 

This requirement calls out the mean time to restore the system, including 
hardware and software, from a system reload and from routine maintenance. 

e. Environment Condition (R.1.5) 

This requirement refers to the location and space with respect to 
temperature where the system will be operated under specific environment conditions. 

2. Design and Construction Requirements (R.2.0) 

The design and construction requirements depicted in Figure 13 comprise the 
requirements for data collection, data reporting, Navy Marine Corps Intranet (NMCI) 
compliance, and print and save. 



Figure 13. Design and Construction Requirements 
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a. Data Collection (R.2.1) 

The system shall be designed to collect data either by manually entered 
data from the user interface or automatically from an external file or database. 

b. Data Reporting (R.2.2) 

The system shall be designed to generate and display data as specified in 
the performance section (R.1.1). 

c. NMCI Compliance (R.2.3) 

The system shall be designed to comply with NMCI. 

d. Print and Save (R.2.4) 

The system shall have the capability to Print and Save the data. 

3. Components Level Requirements (R.3.0) 

The component level requirements identified the system design requirements with 
respect to the hardware and software. Since the primary sources of information for the 
DAS reside on existing computer network devices and servers, the DAS must also 
contain components that can interface with these servers and retrieve necessary 
information. Therefore, at a minimum, the two primary components of the DAS include 
both hardware and software as depicted in Figure 14. Figure 14 shows the hierarchy of 
Component Level Requirements that were refined into two different categories, hardware 
components and software components. 
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Figure 14. Components Level Requirements 

a. Hardware (R.3.1) 

The system shall use Commercial Off-the-Shelf (COTS) hardware that is 
capable of supporting the design characteristics defined in the characteristics section 

(RIO)- 

b. Software (R.3.2) 

The system shall use COTS software that is capable of supporting the 
design characteristics defined in the characteristics section (R. 1.0) 

C. FUNCTIONAL REQUIREMENTS 

The team elected to utilize Vitech’s CORE® software suite to analyze 
requirements. CORE® is a tool specifically designed for SE, facilitating simple steps 
from requirement analysis to architecture design and then to testing. After defining the 
stakeholder requirements and inputting them into CORE®, the team moved on to define 
the system functions necessary to satisfy the requirements. Most functions were defined 
using past studies, surveys, benchmarking, and team member’s personal experience with 
the available tools for data aggregation. The team drafted a list of needs, which was 
reviewed and updated through several revisions by stakeholders in order to develop the 
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final list of functions, which can be found in Appendix B. This final list was entered into 
CORE® and defined in a hierarchal format that allowed top functions to be decomposed 
into more detailed lower level functions. A total of four levels of decomposition were 
created in CORE®. 

Figure 15 provides a high level view of the functions required to aggregate data 
and how the flow of data is passed from one function to the other. After the data is 
received by DAS, it is processed, analyzed, and reported. The output data is displayed to 
the end user in the format requested. The end user can save, print or generate a report to 
support the issue they are tracking. 



Figure 15. System Function Flow Diagram 
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D. INPUT-OUTPUT REQUIREMENTS 

The input requirements of DAS include the user and/or fleet input data and the 
fleet maintenance data infrastructure. This process is illustrated in Figure 16. The output 
requirements include numerous displays and reports. Reports include: 1) system status 
reports, 2) system RMA reports, 3) system assessment reports, 4) logistics reports, 5) 
historical system performance reports, and 6) historical maintenance reports. In addition 
to reports, the output requirements also include: 1) training data, 2) system, ship, and 
Point of Contact (POC) information, 3) system performance trend data, 4) RMA data, 5) 
maintenance cost data, 6) logistic data, 7) logistics cost data, and 8) Question and Answer 
(Q&A) data. At the user interface, the system will display troubleshooting procedures for 
the following: 1) common equipment failures, 2) corrective maintenance data, 3) 
technical support information, 4) logistics data, 5) RMA and trend data, 6) fleet training 
deficiency data, 7) fleet readiness data, and 8) fleet costs. 
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Figure 16. Provide Data Aggregation Capability (IDEFO) 


48 


























































































Figure 17 provides an enlarged excerpt taken from Figure 16. It shows a focused graphic 
of the Obtain Data and Process Data blocks in the DAS’ IDEFO. 



Figure 17. Enlarged Excerpt Taken From DAS IDEFO 

E. FUNCTIONAL ANALYSIS AND ALLOCATION 

As defined in System Engineering and Analysis, 

The functional analysis is an iterative process of translating system 
requirements into detailed design criteria and the subsequent identification 
of the resources required for system operation and support. It includes 
breaking requirements at the system level down to subsystem, and as far 
down the hierarchical structure as necessary to identify input design 
criteria and/or constraint for the various elements of the system. The 
purpose is to develop the top level system architecture, which deals with 
both ‘requirements’ and structure (Blanchard and Fabrycky 2011, 86). 

DAS development began with a physical context diagram of the initial system concept as 

shown in Figure 18. The DAS is highlighted by the dotted box. The input and output 

interfaces to and from DAS are covered later in this section. This context diagram created 

a system boundary which helped to scope and bound the project. The context diagram 
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also describes the external interfaces and the relationships between the developed system 
and the external systems. Once finalized, the context diagram provided the foundation for 
the DAS architecture. 



Figure 18. Physical Context Diagram 


1. Functional Decomposition and Hierarchy 

The functional hierarchy describes the high level functions needed to meet the 
system requirements. These high level functions were then further decomposed in an 
iterative process to determine lower level functions to a level that was sufficient to define 
the system architecture. The functional hierarchy that was determined after completing 
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the requirements analysis is shown in Figure 19. The second level system functions are: 
1) provide external interface, 2) obtain data, 3) process data, 4) analyze data, 5) report 
data, 6) display data, and 7) print and save data. More detailed functions are further 
defined at the third level as indicated in Figure 19. 
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hier Provide Data Aggregation Capability 




Project: 

Distance Support Data Aggregation System 

Organization: 

NSWC PHD 

Date: 

December 26, 2D 12 




Figure 19. Functional Hierarchy 
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2. System Functions Description 

The high level system function descriptions are provided in Appendix B. These 
high level system functions are contained within the first, second, and third levels of 
decomposition as described in Figure 19. The team recognized that additional levels 
beyond the third level are necessary to adequately describe the system architecture 
however, due to time constraints the project was limited to only decomposing down to 
four levels. Functional descriptions beyond the third level are contained within the 
CORE® model that was used to develop this project. 

3. Functional Allocation Matrix 

a. Mapping requirements to system functions 

The next step in the architectural development phase was to create an 
allocation matrix that mapped requirements to system functions and system functions to 
physical components. The allocation matrix was an effective tool because it provided 
traceability between the requirements to functions and then functions to physical 
components of the DAS. Traceability was an important consideration for system 
integration to ensure each requirement was allocated to at least one function and all the 
functions included in the architecture were allocated to the physical components. It is an 
important corollary that the aforementioned logic applies in reverse and all physical 
components directly map to functions required by the stakeholders. 

The complete functional allocation matrix can be found in Appendix B. 
Figure 20 provides an excerpt from the matrix due to size constraints. A dot (•) is placed 
in the column and row intersection where a desired function is filled by its corresponding 
requirements and physical components. 
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Figure 20. Mapping Requirements to System Functions 
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b. Mapping system functions to system components 

The functional allocation matrix was created using the functions and the 
physical components designed to perform those functions of DAS. The team did not use 
specific physical components to avoid limiting the type of technology that could be 
integrated. The complete matrix shows that each function was mapped to a physical 
component. In this manner, the allocation matrix provides traceability between system 
functions and physical components. 

4. System Enhanced Functional Flow Block Diagrams 

Accomplishment of the functional analysis is facilitated through the use of 
E nh anced Functional Flow Block Diagrams (EFFBDs). The EFFBD in Figure 21 
provides a flow block diagram of high level system functions derived from the system 
requirements. The main functions of DAS are defined as: 1) provide external interface, 2) 
obtain data, 3) process data, 4) analyze data, 5) report data, 6) display data, and 7) print 
and save data. 
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a. 


External Enhanced Function Flow Block Diagram 


The external function flow block diagram, shown in Figure 22, was 
designed using CORE® was used by the team to help identify the external system 
interfaces. The DAS will need to interface with multiple sources and therefore it is 
critical to identify and understand the external functions necessary to ensure the quality 
of the data targeted for aggregation and reporting. The high level external functions 
identified by the stakeholders include: 1) perform fleet support infrastructure database 
functions, 2) perform NSWC PHD Distance Support web page functions, 3) perform 
stakeholder functions, and 4) ultimately perform ship functions. Figure 22 depicts the 
flow of information and functional relationship from one source to the next. The high 
level controls for each function are shown at the top. These controls include: 1) by 
request, 2) periodic, 3) manual, 4) Internet access, 5) network interface, 6) automatic, and 
7) as needed. Identifying the controls was necessary to identify the access points required 
to execute functions and sub functions. More specifically, to ensure the flow of data to 
and from the DAS was accurate and complete, and to ensure the system interfaces were 
designed accordingly. 
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Figure 22. External Enhanced Function Flow Block Diagram 


58 

















































































b. Provide External Interface Functions Enhanced Flow Block 
Diagram (F.1.0) 

Figure 23 provides more detail in regards to the first DAS function, 
execute system interface (F.1.0). The diagram in Figure 23 shows the controls and the 
specific data processed by this function. To execute the system interface function, system 
users and the fleet support infrastructure database will process data via the network 
interface and Internet access which are highlighted in green color in Figure 23. The 
network interface and Internet access are considered the controls for the external interface 
function. The data processed during this function will include: 1) fleet logistics data, 2) 
fleet technical assist data, 3) ships, system, and point of contact information, 4) fleet 
RMA data, and 5) fleet 3M data. A network provider is also necessary to perform this 
function. The network provider will be responsible for establishing the physical 
connection between the DAS and the external systems. 



Figure 23. Provide External Interface Function (F.1.0) 
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c. Obtain Data Functions Enhanced Flow Block Diagram (F.2.0) 

Figure 24 is also from the CORE® model and provides details in regards to the 
second DAS function, obtain data function (F.2.0). This function is further decomposed 
in Figure 24 to the next lower level to further describe the controls and information 
processed by this function. Data will need to be obtained from multiple sources which 
include: 1) data from user inputs, 2) data from the fleet, and 3) data from the fleet support 
infrastructure. The controls for these functions include: 1) manual, 2) by request, 3) 
periodic, and 4) automatic. In addition to capturing data from multiple sources, the obtain 
data function will also be required to convert multiple data formats to a common format 
so that the data can be processed without loss of data. This is a critical component of 
DAS, to ensure the quality of the data satisfies stakeholder needs. 



Figure 24. 


Obtain Data Function (F.2.0) 
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d. 


Process Data Enhanced Function Flow Block Diagram (F.3.0) 


Figure 25 is another CORE® model that describes the process data 
function (F.3.0). Figure 25 further decomposes this function to five sub functions: 1) 
process general information, 2) process maintenance data, 3) process logistics data, 4) 
process training data, and 5) process RMA data. These sub functions were determined to 
be necessary for DAS to produce the desired products and information. These sub 
functions were further decomposed in CORE® and can be found in Appendix B. The 
controls for this function include: 1) by request, 2) automatic, 3) manual, and 4) periodic. 
The inputs to these sub functions come directly from the obtain data function. In general, 
the process data function involves data filtering, data consolidation, data organizing, data 
comparing, and data categorizing all of which are necessary for effective analyzing and 
reporting which are additional functions to be performed in DAS. 
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Figure 25. Process Data Function (F.3.0) 
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e. Analyze Data Enhanced Function Flow Block Diagram (F.4.0) 

The analyze data function (F.4.0), which is necessary for the ISEAs to 
monitor the effectiveness of system maintenance, logistics support, training, and 
reliability in order to enable continuous system improvements, as well as to facilitate self- 
help capabilities for the fleet, is decomposed in CORE® to four sub functions as shown 
in Figure 26. These sub functions include: 1) analyze maintenance data, 2) conduct 
system performance trends, 3) compute system Ao and Inherent Availability (Ai), and 4) 
conduct cost analysis. These sub functions are further decomposed in CORE® and 
included in Appendix B. The four sub functions are necessary for DAS to fully analyze 
the formatted data and produce useful information for the stakeholders. The inputs from 
the process data function include: 1) maintenance data, 2) reliability data, 3) logistics 
data, and 4) training data. The information that is produced by the analyze data function 
includes: 1) technical assistance metrics, 2) CASREP metrics, and 3) system and 
component failure metrics. 
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Figure 26. Analyze Data Function (F.4.0) 
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f. Report Data Function Flow Block Diagram (F.5.0) 

The outputs of the analyze data function (F.4.0) are fed directly into the 
report data function (F.5.0) as shown in the CORE® model in Figure 27. The report data 
function was decomposed to four sub functions that include: 1) generate system 
assessment reports, 2) generate logistics reports, 3) generate system status reports, and 4) 
generate system RMA reports. These sub functions are further decomposed in CORE® 
and included in Appendix B. As with the previous functions, the controls for this function 
include: 1) by request, 2) automatic, and 3) manual. The reporting data function (F.5.0) 
prepares the data for the display data function (F.6.0) and satisfies the need to provide 
stakeholders with a tool to review and share results from the data analysis process. 
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Figure 27. Report Data Function (F.5.0) 
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Display Data Enhanced Function Flow Block Diagram (F.6.0) 


g- 

Figure 28 is another CORE® model depicting the display data function 
(F.6.0) at a high level. This function was decomposed into five sub functions including: 
1) display fleet support information, 2) display historical fleet data, 3) display corrective 
maintenance, 4) display logistics data, and 5) display RMA analysis data. Further 
decomposition into lower functions was performed in CORE® and included in Appendix 
B. The controls for this function include: 1) automatic, 2) by request, 3) manual, and 4) 
periodic. As previously mentioned, controls were necessary to identify access for 
executing sub functions. Figure 28 also shows examples of some of the information that 
is aggregated to produce the various displays. The aggregated data as inputs to the sub 
functions includes items such as: 1) system configuration, 2) SME POCs, 3) highest LRU 
failures, 4) CASREP metrics, and 5) technical assistance metrics. The various displays 
needed from the report data function include such things as logistics data, RMA data, 
training data, and cost data. The display data function and related sub functions are 
necessary to visually produce useful self-help and trend analysis information for the 
stakeholders. 
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Figure 28. Display Data Function (F6.0) 
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h. Print and Save Function Flow Block Diagram (F. 7.0) 

Figure 29 shows the CORE® model that describes the print and save 
function (F.7.0). Further decomposition into lower sub functions was performed in 
CORE® and included in Appendix B. The control for this function is limited to “by 
request.” The “by request” control was selected to ensure that unnecessary print and save 
actions would be avoided. Figure 29 also shows examples of some of the information that 
would typically be saved and printed. The aggregated data that stakeholders indicated 
would typically be printed and saved includes 1) historical maintenance data, 2) logistics 
reports, 3) system RMA reports, 4) system assessment reports, and 5) historical system 
performance trend data. 



Figure 29. Print & Save Data Function (F.7.0) 
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5. 


External Functions 


Figure 30 shows the interface between the external functions and DAS. In this 
diagram, the DAS receives input data from both the fleet support infrastructure database 
and ship functions, and it outputs data that is sent to NSWC PHD Distance Support web 
page functions for report and display. The data will be requested and accessed by the 
stakeholder via stakeholder functions. 
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Figure 30. Perform Physical Context Functions (IDEFO) 
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The diagram in Figure 31 provides a high level view of the functions required to 
aggregate data and how the data is passed from one function to the other. In short, after 
the data is received, it is processed, analyzed, reported, and then displayed to the users. 
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Figure 31. High Level System Functions IDEFO Diagram 
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F. EVALUATION MEASURES AND METRICS 

Based on stakeholder requirements, the DAS would need to meet the following 
performance requirements: 

• Data Collection Process - the ability to connect and capture available 
information from multiple sources, including the ability to overcome 
incompatibility of sources (i.e., interoperability) 

• Data Quality - the ability to display accurate, useful, reliable, and 
complete data, including historical troubleshooting experience data, repair 
procedures data, and historical technical assist experience data 

• Accessibility - the ability to display information when needed including 
the accessibility of ship-to-shore connectivity and access time of the initial 
request to receipt of information 

• Data Organizing and Processing - the ability to organize data for effective 
analysis. 

Based upon the above performance measures and assistance from stakeholders, 
the team defined the following metrics for the system: 

• Metrics related to data quality 

• Accuracy, usefulness, reliability, and completeness 

• Age of data (how often updated) 

• Metrics related to DAS 

• Availability of data (accessibility) 

• Data processing (how effective at combining) 

• Time of report generation. 

Since the requirements discussed in Chapter II are very general, the team further 
defined them in order to derive metrics that contained measurable attributes. Table 3 
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summarizes the metrics that were defined by the stakeholders as the key metrics to be 
used in development of the system architecture. As discussed previously, the stakeholders 
indicated that the DAS must be effective at aggregating available information so metrics 
related to the quality of the information are important for ensuring that the information 
will be beneficial. 


Requirement 

Metrics 

Objective 

Threshold 

Accuracy (Ability to provide correct and 
consistent results) 

Probability of accuracy = 
99.5% (5 discrepancies per 
1000 data requests) 

Probability of accuracy = 
99% (10 discrepancies per 
1000 data requests) 

Accessibility (Ability to access data via Port 
Hueneme Division (PHD) web page) 

2 seconds (*) 

10 seconds 

Adaptability (Ability to interface with multiple 
application/ database) 

All databases that can be 
accessed defined in the 
requirements 

All databases that can be 
accessed defined in the 
requirements 

Flexibility (Easily to learn and use) 

Non-Proprietary Software 
& Compliant with 
Department of Defense 
(DoD) Standard 

Compliant with DoD 
Standard 

Human Factors (Easily to learn and use) 

Time for new user to 
obtain data t = 3 minutes, 
return user t = 2 minutes 

Time for new user to 
obtain data t = 5 minutes, 
return user t = 3 minutes 

Maintainability (Ability to fault detect and fault 
isolate) 

Mean Time To Repair 
(MTTR) < 1 hour 

MTTR < 2 hours 

Reliability (Reliable to sustain operation) 

1 failure per 12 months 

1 failure per 9 months 

Availability (Operational Availability (A 0 )) 

A 0 > 99.9% 

A 0 > 99% 

Time to Generate Report (System) 

Data rate t = 15 seconds 
per 1 megabyte (MB) 

Data rate t = 20 seconds 
per 1 MB 

Completeness 

Display all available data 
that the system can 
generate from existing 
database 

Display all available data 
that the system can 
generate from existing 
database 

Timeliness (Frequency of data update) 

Upon request 

Daily 


Table 3. Requirement Metrics 


These metrics were used as evaluation measures in the AoA to help determine 
which alternative would best meet DAS requirements. In order to do so, the team split the 
metrics listed in Table 3 into two groups. The first group is the metrics related to data 
quality, which include accuracy, usefulness, reliability, completeness, and so forth, as 
well as the age of data (how often updated). The second group is the metrics related to 
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DAS, which include availability of data (accessibility), data processing (how effective at 
combining) and time of report generation. 

The team decided that it was necessary to determine to what extent each 
alternative in the AoA met these metrics. Thus, a scale from zero (0) to ten (10) was 
implemented to rate each alternative on how well it performed with respect to the metric, 
where a score of zero implied the alternative did not satisfy the metric at all and a score 
of ten meant the alternative satisfied the threshold. Table 4 summarizes the metrics 
related to data quality and Table 5 summarizes the metrics related to DAS. 


Quality Type 

Question 

Metric 

Accuracy 

Does the data reflect a verifiable 
source in a precise way? (Is the data 
correct?) 

Scale 0-10, 10 = best 

Completeness 

Is all necessary data present? 

Scale 0-10, 10 = best 

Consistency 

Are there any contradictions between 
data sets? 

Number of contradictions 
between data sets / 

Number of Data sets 

Data processing 

How effective is system at combining 
data? 

Scale 0-10, 10 = best 

Relevancy 

Is the data applicable and helpful for 
the task at hand? 

Scale 0-10, 10 = best 

Reliability 

Does the obtained answers conform 
the expected answers? 

Number of answers that 
conform the expected 
answers / Total number of 

answers 

Timeliness 

How often is the data updated? 

Number of updates per day 

Usefulness 

Is there any difference in having or 
not having the data for the user? 

Scale 0-10, 10 = best 


Table 4. Metrics Related to Data Quality 
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Characteristic 

Definition 

Metric 

Accessibility 

The time it takes to access the system 
(availability of data). 

Access Time (t = seconds) 

Adaptability 

Complexity scale to interface with 
other systems. 

Scale 0-10, 10 = least 
complex 

Flexibility 

Ease of modification. 

Scale 0-10, 10 = best 

Data Processing 

System effectiveness of combining 
the data. 

Scale 0-10, 10 = best 

Human Factors 

User friendliness, degree of 
automation, displays, controls, 
feedback, and so forth. 

Scale 0-10, 10 = best 

Maintainability 

The ease with which the system can 
be maintained. 

MTTR (t = minutes) 

Mean Maintenance 
Downtime (MMD) (t 
=minutes) 

Reliability 

The ability of the system to perform 
and maintain its function in routine 
and unexpected circumstances. 

Operational Availability 
(Ao), Mean Time Between 
Failures (MTBF) (t = 
hours) 

Time of Report 
Generation 

The time it takes from the request of a 
new report to the point it is available 
for use. 

t = seconds 


Table 5. Metrics Related to DAS 


G. ANALYSIS OF ALTERNATIVES (AOA) 

To find an effective solution for aggregating data, a structured approach, shown in 
Figure 32, was utilized. First, the details of DAS functions were clearly defined and 
entered into CORE®. Once the functions were defined, alternative solutions that 
consisted of new, experimental, and existing systems were identified. The team worked 
with stakeholders to compare, prioritize, and organize the stakeholder requirements using 
a swing weight model. The stakeholder preferences obtained by the normalized weights 
produced by the swing weight model were then used to compare, or map, technical 
characteristics to requirements, functions to technical characteristics, and alternatives to 
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functions using a Quality Function Deployment (QFD) House of Quality (HOQ) model. 
A gap analysis was then conducted to identify the functional gaps of each of the existing 
systems. Finally, a cost benefit analysis was performed to compare alternatives and select 
the most affordable alternative that provided the best solution. Details of each step in this 
approach are discussed in the paragraphs that follow. 



Figure 32. AoA Approach 
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1. Determining Alternative Solutions 

To identify alternative solutions, the team performed a number of online searches 
and brain storming sessions. The team also utilized the information gathered to eliminate 
infeasible solutions. Thus, the team generated the following alternatives to satisfy DAS 
and provide reasoning to why certain alternatives were eliminated: 

• Alternative 1. Do nothing (maintain the status quo). Alternative 1, 
to do nothing, was eliminated because stakeholders indicated that 
to do nothing is unacceptable since the need for improved Distance 
Support is growing every day. The development of DAS has 
significant interest at the highest levels within the NAVSEA 
command. 

• Alternative 2. Modify Sailor training curriculum and teach Sailors 
how to access data from available sources. Alternative 2, to modify 
Sailor training curriculum, was also eliminated due to feedback 
from stakeholders that showed that the increasing burden on 
Sailors to perform their own research is not effective. Sailors just 
do not have the time to conduct their own research. Plus with this 
alternative, there was the possibility of the system having a poor 
response time, limited response quality control, limited automated 
data collection and reporting capability, and thus would not meet 
many of the system requirements. 

• Alternative 3. Perform manual data aggregation by increasing the 
number of shore support personnel. Alternative 3, to perform 
manual data aggregation, was also eliminated because increasing 
the shore based work force is not possible in a fiscally constrained 
environment. Additionally, this alternative would require 
insurmountable life cycle costs due to high labor costs, large time 
delays between data requests and deliveries since everything would 
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be done manually, and not meet all system requirements. Thus, this 
option is simply not feasible at this time and not cost effective. 

• Alternative 4. Develop a “self-help” styled forum in which fleet 
activities can ask the combat systems community for solutions to 
their issues. Experts or other combat system personnel can search 
and answer questions. Alternative 4 was eliminated because 
although it offers limited life cycle costs, after initial development 
costs, it presents a high possibility of poor response time and 
limited data collection and reporting capability. Furthermore, this 
alternative does not offer the required data display capability, 
making it un-useful for shore based activities, and overall does not 
meet all system requirements. 

• Alternative 5. Develop a new database and/or website that would 
collect, combine, and display data. 

• Alternative 6. Modify an existing database and/or website. 

Alternatives 5 and 6 were determined to be feasible based on numerous 
discussions with stakeholders and were thus selected for further analysis. Alternative 5, 
developing a brand new system, and Alternative 6, modifying an existing system, could 
meet every requirement and customer need if cost and time were not factors. Thus, it was 
determined that a cost and risk analysis should be conducted to compare these 
alternatives and are discussed later in this chapter. These analyses would determine the 
cost, schedule, and risk drivers that would impact the development of the system. Before 
these analyses could be conducted, an existing system for Alternative 6 had to be chosen. 

2. Identifying Alternative Existing Systems (Alternative 6) 

The team researched existing systems within the Navy and outside the Navy, 
including commercial systems that could be used as a model for DAS. Numerous systems 
were identified to possess some or most of the functions required for the system. In order 
to ensure that a solution was selected that met the requirements and executed the 
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important system functions; the alternative existing systems were evaluated. Table 6 lists 
the acceptable systems that were identified for further analysis. 


Acronym 

Name 

Host Organization 

ACSRMS 

Aegis Combat System 
Reliability Maintainability and 
Supportability Database 

Naval Surface Warfare Center 
, Port Hueneme Division 
(NSWC PHD) 

ADA 

Albridge Data Aggregation 
(Financial) 

Commercial 

AIDA 

Adaptive Independent Data 
Application 

University of Virginia 

CIM 

Command Issue Management 

NSWC PHD 

DTIC 

Defense Technology 

Information Center 

Assistant Secretary of Defense 
for Research and Engineering 
(ASD (R&E)) 

ESDS 

Engineering and Supportability 
Decision System 

NSWC PHD 

GDSC Remedy 

Global Distance Support 

Center Remedy 

Fleet and Industrial Supply 
Center Norfolk/San Diego 
(FISC NF/SD) 

MFOM 

Maintenance Figure of Merit 

Commander, U.S. Fleet Forces 
Command (CFFC) 

MRDB 

Material Readiness Database 

Naval Surface Warfare Center 
(NSWC) Corona 

NDE-NM 

Navy Data Environment-Navy 
Modernization 

CFFC 

NSLC3M 

NAVSEA Logistics Center - 
Maintenance and Material 
Management 

Naval Supply Systems 
Command (NAYSUP) 
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Acronym 

Name 

Host Organization 

NANOOS VS 

Northwest Associate of 

Network Ocean Observing 
System Visualization System 

State of Washington 

ORTSTARS 

Operational Readiness Test 
System Tech Assist Remote 
Support 

NSWC PHD 

RDAM 

Regional Data Archiving and 
Management 

State of Illinois 

S2E 

Sailor To Engineer 

NSWC PHD 

VAMOSC 

Visibility and Management of 
Operating and Support Costs 

CFFC 


Table 6. Alternative Existing Systems 


a. Mapping Alternatives to Functions 

The team was able to put together a rather extensive list of existing 
systems that could potentially be modified to meet the DAS requirements, so the systems 
were further analyzed in order to gain a better understanding of their functionality. The 
capabilities and functions of each of the identified existing systems were researched and 
defined. Then the functions of each system were mapped to the required system 
functions, which can be seen in Figure 33. 
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Figure 33. AoA Mapping Existing Systems against Functions 


By mapping each of the existing system’s functions to the required DAS 
functions, the team was able to compare and identify the functional gaps for each of the 
existing systems. The systems that had the most functional gaps were then eliminated 
from further consideration one by one until half the number of systems that were 
originally analyzed remained, leaving the top eight systems with the least gaps. The top 
eight systems that were selected for further consideration were ACSRMS, CIM, GDSC 
Remedy, MRDB, NSLC-3M, S2E, Engineering and Supportability Decision System 
(ESDS), and Maintenance Figure of Merit (MFOM). 
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b. Conducting Swing Weights and QFD HOQs to Compare 
Existing Systems 

After down selecting to eight existing systems, the team worked with the 
stakeholders to evaluate and prioritize requirements using a swing weight model. 
Swingwise comparison was used vice pairwise or other simple weighting systems 
because the swingwise comparison considers not only importance but range of variance 
(Parnell and Trainor 2009). One requirement may be the most important to a stakeholder, 
but the range of solutions to meet that requirement may be so small that the overall 
product success is not impacted. A list of top-level requirements was developed by 
meeting with stakeholders and then swing weight methodology was used to create the 
stakeholder attribute rankings. Instead of ranking the requirements against each other in a 
pairwise comparison, the stakeholders were asked to evaluate the full range of the 
specific attribute when comparing. The stakeholders were asked to determine the 
requirement that offers the best improvement from known ranges and to assign a value of 
100 to it. The remaining requirements were then analyzed to determine their range of bad 
to good against the range of the top requirement. For example, if the swing from worst 
case to best case on a specific requirement was 60% as good as the swing for the top 
requirement, it received a score of 60. This formed a utility function based on 
stakeholder’s preferences. Figure 34 shows the net result of this process. 
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Top Level Requirements 

Swing 

Weight 

Utility 

Swing Weights 
normalized 

Rank 

External Interface 

20 

0.021 

14 

Fleet Maintenance Support 
Data and Metrics 

75 

0.080 

5 

Logistics Data 

50 

0.053 

8 

Training Data 

50 

0.053 

8 

RMA Analysis Data 

50 

0.053 

8 

Reports 

75 

0.080 

5 

Human System Integration 

SO 

0.0S5 

3 

Reliability 

100 

0.107 

1 

Maintainability 

33 

0.035 

13 

Environment Condition 

20 

0.021 

14 

Data Collection 

50 

0.053 

8 

Accessible by authorized 
NMCI Users 

70 

0.075 

7 

Data Reporting 

50 

0.053 

8 

NMCI Compliance 

SO 

0.006 

3 

Hardware Requirements 

10 

0.011 

16 

Software Requirements 

10 

0.011 

16 

Fleet Access 

S5 

0.101 

2 


Figure 34. Swing Weight Utility Function for Top Level Requirements 


A QFD HOQ model was then used to prioritize technical characteristics 
against top-level requirements. QFD HOQ was chosen based on the focus of the 
stakeholder requirements. As the main task for this project was to design a real system for 
supporting the USN fleet, there needed to be a logical path from needs to a solution. 
“HOQ constitutes a team approach to help ensure that the ‘voice of the customer’ is 
reflected in the ultimate design” (Blanchard and Fabrycky 2011, 82). The normalized 
weights obtained from the top-level requirements swing weight matrix, shown in Figure 
34, were used as inputs into the HOQ shown in Figure 35. This method for analysis 
provides traceability from stakeholder requirement evaluations to technical characteristics 
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to system functions to alternative solutions, allowing the team to select an alternative 
solution based on stakeholder preferences (Blanchard and Fabrycky 2011). 

On the HOQ, the top-level requirements were the “What’s” and the key 
technical characteristics were the “How’s” of the DAS. The technical characteristics 
include aspects that affect the design and operation that can be measured with respect to 
the current requirements. The HOQ was also provided to the stakeholders to obtain an 
indication of the stakeholders’ judgment of the impact of the technical characteristics on 
the requirements. The following non-linear scale was used by stakeholders to indicate the 
weight of impact of technical characteristics on requirements: 


Not related or low importance left blank 

Necessary 1 

Important 3 

Critical 9 
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Technical Characteristics (Hows) 

Top Level Requirements (Whats) 

Weight 

Accuracy 

Accessibility 

j 5 

ra 

-i—' 

Cl 

in 

TJ 

< 

Completeness 

Flexibility 

Human Factors 

Maintainability 

Reliability 

Timeliness 

Time of Report Generation 

External Interface 

0.021 


9 

9 


9 




3 


Fleet Maintenance Support Data and Metrics 

0.080 

9 



9 


3 



3 

9 

Logistics Data 

0.053 

9 



9 


3 



3 

9 

Training Data 

0.053 

9 



9 


3 



3 

9 

RMA Analysis Data 

0.053 

9 



9 


3 



3 

9 

Reports 

0.0-80 

9 



9 


3 



3 

9 

Human System Integration 

0.006 



3 


3 

9 





Reliability 

0.107 


3 



1 


9 

9 


3 

Maintainability 

0.035 


3 



1 


9 

9 


3 

Environment Condition 

0.021 



1 


1 

9 





Data Collection 

0.053 

9 

3 

3 

9 

3 


1 

1 

9 

9 

Accessible by authorized NMCI Users 

0.075 


9 

1 


1 






Data Reporting 

0.053 

9 

3 

3 

9 

3 


1 

1 

9 

9 

NMCI Compliance 

0.096 


9 

1 


1 






Hardware Requirements 

0.011 


3 

9 


3 

1 

1 

1 

3 

9 

Software Requirements 

0.011 


3 

9 


3 

9 

1 

1 

3 

3 

Fleet Access 

0.101 

3 

9 


3 


9 

3 

9 

9 

9 

Total 

1.00 


Weighted Performance 


4.142 

3.44-8 

1.183 

4.142 

1.197 

3.033 

1.708 

2.316 

2.958 

5.303 

Percent Performance 


0.141 

0.117 

0.040 

0.141 

0.041 

0.103 

0.058 

0.079 

0.101 

0.180 


II.I.I ■ I 


Figure 35. HOQ1 Requirements to Technical Characteristics 


From Figure 35, using the normalized weights produced by the HOQ, it can 
be concluded that Time of Report Generation, Accuracy, and Completeness were the most 
critical technical characteristics for the DAS. The HOQ results suggested that the most 
critical characteristics were related to the overall goal of providing a fast, easy to use, 
useful, and effective system to the user. Furthermore, it is important to note that the HOQ 
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results aligned with the feedback obtained from the stakeholders’ needs analysis, further 
demonstrating that the results of the process followed by the team accurately reflects the 
preferences of the stakeholders. 

A second QFD HOQ, shown in Figure 36, was used to map technical 
characteristics to functions. The normalized weights obtained from the previous QFD HOQ 
were used as inputs into the second HOQ, continuing with the traceability from 
requirements to technical characteristics to functions. The HOQ was also given to the 
stakeholders to obtain an indication of the stakeholders’ opinion of the impact of the 
functions on the technical characteristics and the same non-linear scale was used. 
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Functions (Hows) 

technical Characteristics (Whats) 

Weight 

Provide External Interface 

Provide User 1 nt erf ace 

Obtain Data 

Obtain Data from User Inputs 

Obtain Data from Fleet 

Obtain Data from Fleet Support Infrastructure 

Process Data 

Process General Information 

Process Maintenance Data 

Process Logistics Data 

Process Training Data 

Analyze Data 

Analyze Maintenance Data 

Conduct System Performance Trending Analysis 

Compute System Ao/Ai based on RMA data 

Conduct Cost Analysis 

Report Data 

Generate System Assessment Report 

Generate Logistics Report 

Generate System Status Report 

Generate System RMA Report 

Display Data 

Display Fleet Support Information 

Display Historical Fleet Data 

Display Corrective Maintenance Information 

Display Logistics Information 

Display RMA Analysis Data 

Print Data 

Accuracy 

0.141 


3 

9 

9 

9 

9 

9 

9 

9 

3 

3 

9 

9 

9 

9 

3 

9 

9 

3 

9 

9 

9 

9 

9 

9 

3 

9 

1 

Accessibility 

0.117 

9 

9 

3 

3 

3 

3 























Adaptability 

0.040 

9 

1 

9 

9 

9 

9 











3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

3 

9 

Completeness 

0.141 


3 

9 

9 

9 

9 

9 

9 

9 

3 

3 

9 

9 

9 

9 

3 

9 

9 

3 

9 

9 

9 

9 

9 

9 

3 

9 

1 

Flexibility 

0.041 

9 


9 

9 

9 

9 

3 

3 

3 

3 

3 

1 

1 

1 

1 

1 

3 

3 

3 

3 

3 

9 

9 

9 

9 

9 

9 

9 

Human Factors 

0.103 


9 















9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

Maintainability 

0.058 

3 

3 

3 

3 

3 

3 











1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Reliability 

0.079 

3 

9 

3 

3 

3 

3 











1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

Timeliness 

0.101 

1 

9 

9 

9 

9 

9 

3 

3 

3 

3 

3 


















Time of Report Generation 

0.180 

3 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

9 

3 

3 

3 

3 

3 

3 

3 

Total 

1.00 


Weighted Performance 


2.8 

6.3 

6.5 

6.5 

6.5 

6.5 

4.6 

4.6 

4.6 

2.9 

2.9 

4.2 

4.2 

4.2 

4.2 

2.5 

5.5 

5.5 

3.8 

5.5 

5.5 

4.6 

4.6 

4.6 

4.6 

2.9 

4.6 

2.6 

Percent Performance 


0.022 

0.049 

0.051 

0.051 

0.051 

0.051 

0.036 

0.036 

0.036 

0.023 

0.023 

0.033 

0.033 

0.033 

0.033 

0.020 

0.043 

0.043 

0.029 

0.043 

0.043 

0.036 

0.036 

0.036 

0.036 

0.023 

0.036 

0.020 

































Figure 36. HOQ2 Technical Characteristics to Function 
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From Figure 36, using the normalized weights produced by the second HOQ, the key 
functions identified include: 1) provide user interface, 2) obtain data, 3) obtain data from 
user inputs, 4) obtain data from fleet, and 5) obtain data from fleet support infrastructure. 

Finally, the third QFD HOQ, as shown in Figure 37, mapped functions to 
existing systems. As was the case with the previous HOQs, the normalized weights from 
the second HOQ were entered as inputs for this HOQ. Furthermore, as with the previous 
HOQs, the HOQ was provided to the stakeholders to obtain an indication of the 
stakeholders’ opinion of the impact of the existing systems on the functions and the same 
non-linear scale was used. The team used the third HOQ in order to rank the previously 
identified top eight existing systems and come up with the performance weight for each 
system. 
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Exist in 

Systems 

Functions 

Weight 

3 

vi 

LJJ 

m 

IE 

a 

< 

rd 

in 

_l 

L- r : 

Z 

Q 

I 

5 

lu 

_! 

LJ 

3 

CJ 

2D 

Prc - ide External Interface 

0.022 

□ 

9 

9 

9 

□ 

3 

3 

^ i 

Provide User interface 

0.049 

1 

3 

9 

9 

3 

3 

3 

9 

Obtain Cata 

0.051 

□ 

9 

3 

9 

9 

9 

9 

9 

Obtain Cata from User Inputs 

0.051 

3 

3 

9 

1 

3 

3 

9 

3 

Obtain Cata from Fleet 

0.051 




3 





Obtain Cata from Fleet Support Infrastructure 

0.051 

0 

9 

3 


1 

9 

9 

1 

Process Cat a 

0.036 

Q 

9 

3 

3 

9 

3 

3 

9 

Process General Information 

0.056 



3 

1 


9 

1 


Process ! 'aintenance Cat a 

O'. 03 6 

Q 

9 

3 

1 

9 

3 

1 

9 i 

Process Logistics Cata 

O'. 02 3 

0 

9 


3 

9 



9 

Process “raining Cata 

0.023 




1 




3 

Analyze Cat a 

0.033 

0 

9 

1 

3 

9 

1 

3 

9 

Analyze Maintenance Cata 

0.033 

□ 

9 

3 

9 

a 

1 

3 

9 

Conduct System Performance “rending Analysis 

0.033 

9 

9 



Q 



9 

Compute System Ac/Ai based on RMA data 

O'. 03 3 

3 

9 



9 



9 

Conduct Cost Analy sis 

0.020 

9 

9 






9 

Report Cat a 

0.043 

o 

9 

9 

3 

9 

3 

3 

9 

Generate System Assessment Report 

0.043 

o 






1 


Generate Logistics Report 

0.020 

Li 

3 


9 

9 



3 

Generate System Status Report 

0.043 

3 

1 



3 




Generate System RMA Report 

0.043 

9 

1 



3 



1 

C is play Cata 

0.036 

9 

9 

9 

9 

Q 

9 

9 

9 I 

C is play Fleet Support Information 

0.036 



9 

3 


3 



C is play Historical Fleet Cata 

0.036 

9 

9 

3 


9 

9 

1 

9 i 

Display Corrective Maintenance Information 

0.036 



9 



3 

9 


Display Logistics Information 

0.023 

3 

9 

1 

3 




9 i 

Display RMA Analysis Cata 

0.036 

9 

9 



□ 



9 i 

Print Cata 

0.020 

9 

9 

9 

9 

Q 

3 

3 

s i 

Total 

1.00 



Weighted Performance 

6.0B4 

5.53C 

3.525 

3.033 

5.037 

2.937 

2.330 

5.440 

Percent Performance 


0.176 

0.160 

0.102 

0.033 

0.147 

0.035 

0.033 

0.153 



Figure 37. HOQ3 Functions to Existing Systems 
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From Figure 37, by comparing the performance weights produced by the HOQ, the top 
four existing systems were identified, which were ESDS, ACSRMS, MFOM, and 
MRDB. 


c. Gap Analysis 

In order to identify the best Alternative 6, an existing system that could be 
modified for DAS, from the top four systems identified by using Swing Weights and 
QFD HOQs, the team used the third QFD HOQ, which mapped existing systems to 
functions, to conduct a functional gap analysis. All of the functions that were missing by 
each of the top four existing systems were listed. The results can be seen in Table 7. 
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Existing Systems 

Gaps (Functions) 

Engineering and Supportability 
Decision System (ESDS) 

Obtain Data from Fleet 

Process General Information 

Process Training Data 

Display Fleet Support Information 

Display Corrective Maintenance Information 

Aegis Combat System Reliability 
Maintainability and 

Supportability Database 
(ACSRMS) 

Obtain Data from Fleet 

Process General Information 

Process Training Data 

Generate System Assessment Report 

Display Fleet Support Information 

Display Corrective Maintenance Information 

Maintenance Figure of Merit 
(MFOM) 

Obtain Data from Fleet 

Process General Information 

Process Training Data 

Conduct Cost Analysis 

Generate System Assessment Report 

Display Fleet Support Information 

Display Corrective Maintenance Information 
Display Logistics Information 

Material Readiness Database 
(MRDB) 

Obtain Data from Fleet 

Process General Information 

Process Training Data 

Generate System Assessment Report 

Display Fleet Support Information 

Display Corrective Maintenance Information 


Table 7. Gap Analysis Chart 


The number of gaps for each system was then used as a metric to evaluate 
the remaining systems. Table 7 shows that ESDS has only five functional gaps while 
ACSRMS and MRDB have six and MFOM has eight. Furthermore, it can be noted that 
all of ESDS’ functional gaps are also functional gaps for the other three systems. In other 
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words, the other three systems had at least the same functional gaps as ESDS. As a result, 
the best solution based on the least amount of functional gaps was ESDS. 

After identifying ESDS to be the existing system with the least functional 
gaps, the team continued the AoA process by examining system documentation for each 
of the four systems. The following findings resulted from that process: 1) ACSRMS was 
no longer supported by the contractor, thus it was eliminated as a potential solution, 2) 
the results of MFOM and MRDB analyses showed that ESDS already aggregates data 
from both systems and 3) MFOM and MRDB have limited data aggregation capability, 
significantly increasing the amount of effort that would be required to make 
modifications. Since ESDS already aggregates data from MFOM and MRDB, and both 
systems have limited data aggregation capability, the team determined that modifying 
ESDS was the most suitable existing system option for Alternative 6 that would meet the 
needs of the stakeholders and solve the problem. To distinguish between the existing 
ESDS and the modified ESDS, the team has acquired the term “ESDS Plus” (ESDS+) 
and has utilized it for the rest of this report. 

H. COST ANALYSIS 

In today’s budget constrained environment, all government spending is subject to 
scrutiny. Fleet and shore based activities are under extreme pressure to minimize costs, 
but weapon system availability requirements are higher than ever. While many efforts to 
increase fleet readiness have been extremely costly, Distance Support can reduce costs 
for shore-based activities and the ships they support. Although initial development costs 
can be high, by reducing travel requirements, supporting system operability, and lowering 
MTTR, Distance Support is an extremely valuable tool that can provide a ROI in a very 
short period of time. 

1. Costs Overview 

The costs for a Distance Support system can be broken down into four categories: 

1) development costs, 2) life cycle costs, 3) disposal costs and 4) savings. Distinguishing 

between these costs will help to estimate initial costs, and extrapolate over time to 

determine life cycle costs at specific future dates. Disposal costs will be incurred when 
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the system is replaced and disposed of in the future, and with these costs accounted for, 
overall total life cycle cost can be determined. 

a. Development Cost 

Development costs include all costs associated with the development of a 
new system. Major costs associated with development costs are 1) stakeholders’ needs 
analysis, 2) requirements analysis, 3) programming costs, and 4) early beta testing 
debugging efforts. These costs are non-recurring, as they take place only during the 
development of the system. In the case of systems with hardware, this may include 
installation and the testing of the hardware systems when it is installed or fielded. 

For the purpose of this project, the team assumed that the DAS will utilize 
basic processing requirements, and therefore will not require extensive hardware 
development or installation. This will both reduce the installation costs, as well as 
disposal costs. 


b. Life cycle Cost 

Life cycle costs include all costs required to support the fielded active 
system. These costs include 1) technical support, 2) training, 3) monitoring and 
troubleshooting costs, 4) debugging efforts, 5) information assurance updates, and 6) 
incremental updates to keep the system running effectively. 

For DAS, the majority of life cycle costs will be incurred through 
debugging and troubleshooting, information assurance, and incremental updates. An 
automated DAS will require minimal oversight, so full time support employees are not 
likely to be necessary to the support of the system. Periodic maintenance contracts to a 
contractor may suffice, which will help maintain low life cycle costs. 

Current NSWC PHD funding given to ESDS for life cycle support is 
approximately $245,000 per year. In addition to traditional life cycle support efforts, this 
includes contractor support to help train NSWC PHD engineers to use the system. This 
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allocation of monies also funds full time contractors to support data acquisition support 
for NSWC PHD command-sponsored studies and briefings such as SEAR briefings for 
combat system elements. 

c. Disposal Costs 

Disposal costs include all costs associated with disposing the final system 
at the end of its life, including 1) system hardware removal costs, 2) destruction or 
demilitarization costs, and 3) physical disposal costs. In some cases, parts of the systems 
can be demilitarized and reutilized as a cost avoidance technique. 

For a software focused DAS, with minimal hardware installation, disposal 
costs will be negligible in comparison to development costs, life cycle costs, and savings, 
and therefore can be ignored for this project. 

d. Savings 

Distance Support has the ability to save costs in several important areas. 
Effective Distance Support applications can reduce repair time, reduce the number of 
onsite CASREP SME technical assists, and most importantly stop system issues from 
preventing a ship to complete a mission. 

For the stakeholders at NSWC PHD, DAS could result in major travel cost 
reductions. Navy Sailors primarily submit CASREPs to notify shore based activities of 
major system failures. NSWC PHD, as the ISEA for many of these Navy systems, is 
called upon to fix CASREPs. These engineering efforts supported by shore-based 
activities such as NSWC PHD often require an on-site technical subject matter to visit the 
ship in need. These trips are costly due to travel expenses and labor, so an overall 
reduction in travel can have major cost savings for shore based activities. 

(1) Time Savings - The effective utilization of Distance 
Support will save both fleet end users and shore based support activities valuable time 
when working to correct system issues. This means Sailors have to spend less time 
troubleshooting their systems, and they can spend more time on other tasks and auxiliary 
functions. 
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(2) Value of Reduced Downtime - The most valuable aspect of 
effective Distance Support is the improvements to Ao and reduction in system downtime. 
Determining the value of reduced system downtime can be a difficult and subjective 
determination. 

If a system failure is critical, the impacts could greatly increase 
costs. There is usually not a second ship that can immediately fill the mission 
requirements if a deployed ship has a major system failure. This means in time of 
national crisis or international tensions and a USN ship is required to be deployed it is 
imperative that ship remains at maximum operational readiness levels. 

2. Development Cost Analysis through Constructive Systems 
Engineering Cost Model (COSYSMO) 

Through the AoA, the team determined two options to meet the DAS 
requirements: 1) modify ESDS and 2) build a new Distance Support system. The team 
determined the development costs associated with both options by using the COSYSMO 
Version 2.0. COSYSMO 2.0 is a systems engineering cost estimation tool that was a 
development effort between NPS and University of Sothem California (USC), built on a 
framework developed by COSYSMO model developer Dr. Ricardo Valerdi of 
Massachusetts Institute of Technology (MIT). COSYSMO can be effectively used by 
systems engineers to estimate cost for developing software systems. 

COSYSMO can be found at http://cosysmo.mit.edu/wp-content/uploads/ 
2010/1 l/academicCOSYSMO_2.0.xls and instructions on it use can be found at several 
sites, including: http://powershow.com/viewl/ld7deb-NDFiY/Towards_COSYSMO_20_ 
Future_Directions_and_Priorities_CSSE_Annual_Research_Review_Los_Angeles_CA_ 
powerpoint_ppt_presentation. COSYSMO is a model used to compute an estimated 
number of person-months of a project will require. COSYSMO has been calibrated with 
the data sets from multiple DoD organizations and companies to enhance the accuracy of 
the model. 

The application of COSYSMO has been used to determine which of the two 
options would require less engineering effort to develop. The specific version of the tool 
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that the team used was COSYSMO 2.0 because it allows users to account for redesign 
efforts. This was necessary to compare the new system to the estimated costs of 
redesigning ESDS to meet the requirements. 

COSYSMO takes in a specific set of pre-defined user-inputs. The COSYSMO 2.0 
Software Documentation, titled Systems Engineering Cost Estimation with COSYSMO, 
which was written by Ricardo Valerdi from the Massachusetts Institute of Technology in 
2008, provides extremely specific definitions for each degree of complexity for factors 
that will drive software size, and software cost. By making the definitions of each degree 
of complexity, there is less ambiguity when predicting input parameters. As a result, 
COSYSMO more accurately estimates costs across a variety of platforms and a wide 
range of users. The following section covering COSYSMO inputs describes the pre¬ 
defined inputs that a COSYSMO user needs to determine for their system and select 
when using the cost estimation tool. 

a. COSYSMO Inputs: 

Size Drivers: The numbers of requirements, algorithms, interfaces, and 
operational scenarios to be entered into COSYSMO as inputs are broken down into 
several categories. The size drivers are differentiated and entered into COSYSMO based 
on degree of complexity (easy, nominal, and difficult). 

(1) COSYSMO Size Drivers-Size drivers are factors that 
influence the final developed system’s software size and complexity. Each input directly 
increases the number of source lines of code (SLOC) of the final system. Size driver 
inputs for COSYSMO are as follows for a New System: 

• Number of Requirements 

• Number of Interfaces 

• Number of System Specific Algorithms 

• Number of Operational Scenarios. 
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For a redesigned system, the inputs are the same, but each driver is 
broken down further into these categories: 1) reused, 2) modified, 3) deleted, 4) adopted 
and 5) managed. These inputs are then fed through a ruse algorithm to convert these 
inputs to an equivalent number of new input parameters. 

(2) COSYSMO Cost Drivers-cost drivers are input parameters 
that impact the overall development cost of the system based on factors that do not 
necessarily impact the actual software size. Cost drivers are broken down into two 
different categories: application factors and team factors. Application factors impact the 
complexity of the system due to the installed platforms, documentation requirements, and 
other general factors that complicate the operational scenario of the final system. Team 
factors are the various factors that impact the development team’s ability to develop and 
build the system. 

COSYSMO Cost Drivers are all also broken down by complexity: 
1) very low, 2) low, 3) nominal, 4) high, 5) very high, and 6) extra high. 

Application Factors: 

• Requirements Understanding 

• Architecture Understanding 

• Level of Service Requirements 

• Migration Complexity 

• Technology Maturity 

• Documentation Match to Life Cycle Needs 

• Number and Diversity of Installations/Platforms 

• Number of Recursive Levels of the Design 

Team Factors: 

• Stakeholder team cohesion 

• Personnel/team capability 
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• Personnel experience/ continuity 

• Process capability 

• Multisite coordination 

• Tool Support 

Figures 38 and 39 show the input variables that were used to run 
the COSYSMO analysis. Figure 38 depicts the inputs for ESDS+ while Figure 39 depicts 
the inputs used for a New System. 
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System Size 

# Df System Requirements 

# of System Interfaces 

# of Algorithms 

# of Operational Scenarios 


Expert COSYSMO - Systems Engineering Cost Model Risk Advisor 



Easy 

Nominal 

Difficult 

26.45 

24.05 

2 

0.65 

6.45 

13 

3.3 

4.8 

2.6 

0.15 

0.15 

1 
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52-103 


System Size Probability Distribution 
# Iterations 


275 271 



109-136 1136-164 1164-191 |191-21S 1218-246 


System Equivalent Size 


Distribution Type Triangle 


System Cost Drivers 
Requirements Understanding 
Architecture Understanding 
Level of Service Requirement 
Migration Complexity 
Technology Risk 

System Labor Rates 

Cost per Person-Month (Dollars) 8000 


High 

3 

High 

0 

High 

w 

High 

~w 

Nominal 

T 


Documentation 


# of Recursive Levels in the Design 


PersonnelTeam Capability 


Very High |r] 

Extra High T] 

Nominal 

T 

Very Low 

-1 

High 

W 


Personnel Experience/Continuity 

Process Capability 
Multisite Coordination 
Tool Support 


High 


0 


High 


Nominal 


High t 


Calculate 


Figure 38. Expert COSYSMO Inputs - ESDS+ 
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System Size 

# of System Requirements 

# of System Interfaces 

# of Algorithms 

# of Operational Scenarios 


Expert CO SYS MO - Systems Engineering Cost Model Risk Advisor 



Easy 

Nominal 

Difficult 

31 

30 

2 

1 

9 

2 

5 

15 

6 

1 

1 

1 



143-190 


System Size Probability Distribution 


# iterations 



190-238 12 38-286 12S6-334 | 334-382 | 352-43-0 
System Equivalent Size 


Distribution Type Triangle _rj 


System Cost Drivers 


Requirements Understanding 

Architecture Understanding 

Level of Service Requirements 

Migration Complexity 

Technology Risk 

High 


Nominal 

d 

High 

d 

Nominal 

T 

Nominal 

2d 

System Labor Rates 

Cost per Person-Month (Dollars) 3000 


Documentation 

# and Diversity of Installations/Platforms 

# of Recursive Levels in the Design 
Stakeholder Team Cohesion 
PersonneVTeam Capability 


Very High 

T 

Extra High 

T 

Nominal 

T 

Very Low 

T 

Nominal 

T 


Personnel Experience/Continuity 

High 

T 



Process Capability 

Multisite Coordination 

Tool Support 

Nominal 


Nominal 

d 

High 

T 


Calculate 


Figure 39. Expert COSYSMO Inputs - New System 
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b. COS YSMO A nalysis: 

To determine COSYSMO input values, the system requirements from the 
requirements analysis was used. The complexity of each requirement was used to 
determine the complexity of each, to determine the approximate number of system- 
specific algorithms that would be needed, and to identify the number of system interfaces 
and the complexity of each of those interfaces. Next, each function was mapped to the 
two systems to be compared to determine which of the functions would lead to a new 
requirement for development or an existing requirement already completed that can be 
modified and reutilized. 

For the new system, each of these requirements was entered into 
COSYSMO as new requirements. For the improved ESDS system (ESDS+), each 
function had to be determined as a new, reused, modified, adopted, or managed 
requirement. All of these values and their rankings were then entered into COSYSMO. 

In 2012, NSWC PHD conducted a funding profile analysis and created a 
report titled ESDS Cost Breakdown. In this analysis, NSWC PHD estimated costs of 
future ESDS overhauls to include additional functionality desired by NSWC PHD 
management. This report was used to compare the COSYSMO outputs to verify the cost 
estimates. 


3. Development Cost Estimates from COSYSMO 

The outputs from the COSYSMO Analysis are as shown in Table 8. 


Option 

Estimated Effort 

(Person-Months) 

Estimated Effort Less 

Tech. Management 

ESDS+ 

102 

85 

New System 

258 

214 


Table 8. COSYSMO Analysis Outputs 
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The team’s assessments indicate that the estimated development effort to 
modify ESDS to meet the new requirements will cost 40% of the total development cost 
required to build a new system. 

COSYSMO computed approximately 17% of the total cost of the project 
as “Technical Management Costs.” This expense was eliminated because NSWC PHD 
contractors will be conducting the work, with government oversight covering the 
majority of technical management efforts. It was estimated that one person month was 
160 hours of labor, and a software engineer contractor’s cost ranged between $50.00/hour 
to $100.00/hour. Taking these factors into account, the resulting estimates are shown in 
Table 9. 


Option 

Software Engineer 

Hourly Cost 

($50/hour) 

Software Engineer 

Hourly Cost 

($100/hour) 

ESDS+ 

$680,000 

$1,360,000 

New System 

$2,064,000 

$4,128,000 


Table 9. COSYSMO Analysis Outputs 


In the study, ESDS Cost Breakdown, cost estimates to upgrade the functionality of 
ESDS was in the range of $818,000 per major overhaul. Thus the team felt confident that 
their AoA cost analysis results were realistic. 

4. Cost Analysis - Monte Carlo Simulation 

Expert COSYSMO also has the ability to run a simple Monte Carlo Simulation 
based on the user inputs. The Monte Carlo Simulation allows the user to determine how 
uncertainty in the variables affects the projected outcome based on hundreds or even 
thousands of simulation runs. For this analysis, the Monte Carlo Simulation outputs a 
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range of system development effort costs. Figure 40 shows the Monte Carlo Simulation 
outputs for ESDS+ while Figure 41 shows the Monte Carlo Simulation outputs for a new 
system. 


Monte Carlo Risk Analysis (1000 runs} 

Systems Effort Distribution Function 

# Iterations 

236 



59 


149-67 167-55 155-103 1103-121 1121-139 1139-157 
Effort (Person-Months) 


Systems Effort Confidence Levels 


10% 

| 74 

20% 

| S3 

30% 

| 91 

40% 

| 97 

50% 

1 1 03 

00% 

j 109 

70% 

1116 

so% 

j 124 

90% 

1 1 34 

1 1 00% 

j 1 57 



Your output file is httc://c5se. UBC.edu/tools/data/COSYSUO January 5 2013 00 25 41 237339.txt 

Figure 40. Expert COSYSMO Output Monte Carlo Simulation - ESDS+ 
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Monte Carlo Risk Analysis [1000 runs} 


Systems Effort Distribution Function 

# Iterations 

276 271 



123-169 1169-214 1214-260 1260-305 1305-351 | 351-396 
Effort (Person-Months} 


Systems Effort Confidence Levels 


10% 

1177 

20% 

1203 

30% 

1225 

40% 

1240 

50% 

1256 

S0% 

1269 

70% 

12S7 

50% 

| 306 

30% 

1331 

1 1 00% 

1396 



Ydut output file is httEi /csse.usc.edu/tooisj'data/COSYSMO January E- 2013 00 27 23 4SSSE-2.txt 

Figure 41. Expert COSYSMO Output Monte Carlo Simulation - New System 

As seen in Figures 40 and 41, the range of effort in person-months can vary substantially. 
As a result, there is some noticeable uncertainty in the actual effort required to build the 
DAS solution. This will have to be factored in when drafting the contract for the DAS. 

I. RISK ANALYSIS 

Risk analysis began at the commencement of this research effort, following the 
Risk Management Guide for DoD Acquisition written in 2006. Risk factors were 
included in the cost estimates previously discussed in this report to see if mitigating risk 
factors would affect system development costs. The risk analysis process was to: 1) 
identify risks, 2) analyze the risks identified to determine their severity and probability of 
occurrence and 3) determine how the risks could be mitigated or controlled. Table 10 
shows the adapted severity table to assess risks. 
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Level 

Schedule 

1 

Minimal or no impact 

2 

Able to meet key dates 

Slip < 1 week 

3 

Minor schedule slip. Able to meet key 
milestones with no schedule float 

Slip < 2.5 weeks 

4 

Program critical path affected 

Slip < 1 month 

5 

Cannot meet key program milestones 

Slip > 1 month 


Table 10. Risk Consequence Classification (After Office of the Under Secretary of 

Acquisition, Technology and Logistics 2006) 


The probability of occurrence is as important as the severity and it is categorized 
by the criteria in Table 11. 


Level 

Likelihood 

Probability of Occurrence 

1 

Not Likely 

<10% 

2 

Low likelihood 

<30% 

3 

Likely 

<50% 

4 

Highly likely 

<90% 

5 

Near Certain 

<100% 


Table 11. Risk Likelihood Classification (From Office of the Under Secretary of Acquisition, 

Technology and Logistics 2006) 


Upon judging the severity and probability of a negative event, the specific risk 


identified can be classified by utilizing the chart in Figure 42. “Stop light” colors of red, 
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yellow and green are used to categorize the risk. The goal for this effort was to move any 
identified risks from the red and yellow regions to the green region via mitigation. 



1 2 3 4 5 

Consequence 


Figure 42. 


Risk Assessment Matrix (From DoD 2006) 


The team identified and tracked programmatic and technical risks for the project. 
The following details the analysis of the highest risks of both categories: 

1. Technical Risks: 

For technical risk, there is already a precedent that has been set by the existing 
database and the tool set programmers that exist at NSWC PHD. This existing 
information and the knowledge of NSWC PHD personnel can be leveraged in the 
development of the DAS. Although the other products may not provide a complete 
Distance Support process, they are stable and do perform tasks with data as designed. 
Following the DoD risk management guide, these risks will need to be monitored on 
regular basis and newly identified risks will be added. Figure 43 shows these Technical 
Risks. 
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Risk 

# 

Description 

Likelihood 

Consequence 

Response 

100 

Data cannot be formatted to a 
standard form for 
consolidation 

Low 

Likelihood 

Cannot meet 
key program 
milestones 

Mitigate risk by using 
NSWC PHD ISEA 
Stakeholders to 
ensure data format 
viable 

101 

Data cannot be "pulled" 
correctly to a standard form 
for consolidation 

Low 

Likelihood 

Cannot meet 
key program 
milestones 

Control risk by 
utilizing NSWC PHD 
database experts' 
heuristics to reduce 
likelihood of 
occurring' 

102 

Data being consolidated is 
resident in non-classified and 
classified sources; Getting 
data from unclassified to 
secret enclaves is arduous and 
could cause classified spillage 
if not performed properly 

Low 

Likelihood 

Program 
critical path 
affected 

Ensure all 

programmers are up 
to date in "low to 
high" training and 
utilize established 
protocol for transfer 

103 

HSIand Reliability Deficient in 
Testing 

Low 

Likelihood 

Minor 

schedule slip 

Mitigate/Control by 
using the "build a 
little, test a little" 
technique, not waiting 
for the end of the 
project to get 
feedback 


Risk Assignment 



I J 3 I S 



I J 3 1 S 





i J 3 4 S 



5 1 1 * S 

r ufnc ^ 


Figure 43. Technical Risks 
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2. Programmatic Risks: 

A data aggregation tool is only as good as the data being entered. With this in 
mind, a review of the solutions for issues will be necessary by SMEs for accuracy. Also, 
a review is necessary for ensuring that the tool’s methodology is sound, safe, and 
consistent with the documentation being used and agrees with known best practices. In 
some cases, efficiencies in reporting will be necessary, since many SMEs are obligated to 
track personal highlights (weekly accomplishments for personnel reasons) and complete 
trip reports. The intent is to improve the existing reporting without adding workload to 
the experts who need to be spending their time on providing active support. Figure 44 
shows these programmatic risks. 
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Risk 

# 


200 


201 


202 


Description 

Likelihood 

Consequence 

Response 

Human-In-Loop element is not 
available to ensure 
consolidated data makes sense 
and is accurate 

Low 

Likelihood 

At least one 
requirement not 
met 

Control risk by 
utilizing NSWC PHD 
branch headsto 

ensure SMEs are 
available 

Informative narrative useful 
data not entered in fields 

Likely 

At least one 
requirement not 
met 

Control risk by 
requiring review of 
department chief 
systems engineers 
of the SME input to 
ensure a quality 
product 

DS data from at least one 

NSWC PH D System is not 
available for consolidation 

Low 

Likelihood 

At least one 
requirement not 
met 

Mitigate risk by 
utilizing NSWC 

PHD Department 
Systems Engineers 
to ensure data is 
available 


RiskAssignment 





1 

■ 




l" 




X 


I 2 J 4 5 

CwtHqHKt 



Figure 44. Programmatic Risks 
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3. 


Cost Risks: 


The cost estimation tool utilized was the Expert Constructive Systems 
Engineering Cost Model (Expert COSYSMO). It provided the team with the ability to 
estimate the overall system cost risk by analyzing the cost driver input parameters. This 
estimate was done by using an input comparison table with calibrated risk analysis 
comparing each input against all others and looking for potentially high risk areas. 

Whenever a risk area is identified, Expert COSYSMO provides a risk value and 
attempts to provide a risk mitigation strategy. Expert COSYSMO identified several high, 
medium and low risk areas for both modifying ESDS and building a new Distance 
Support tool. 

Once all risk areas were identified and risk values estimated, an overall risk value 
was calculated by summing all of these values. The final overall risk value will be in the 
range of zero to 702. The risks associated with each option are summarized in Table 12. 
The input and output parameters that went into Expert COSYSMO can be found in 
Appendix C-Risk Analysis Through COSYSMO. 



Number of 

Number of 

Number of 


Option 

Low Risk 

Medium 

High Risk 

Total Risk: 


Areas 

Risk Areas 

Areas 


ESDS+ 

8 

4 

1 

44.7 

New System 

11 

4 

1 

45.7 


Table 12. Risks Associated with Each Option 


The outputs of Expert COSYSMO require review because it does not have insight 
to the systems it compares. The team found that Expert COSYSMO gave a medium risk 
for “ESDS+” because Migration Complexity was rated as high. This assessment was 
determined to be inaccurate because there will be no actual migration of existing ESDS 
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infrastructure, rather the existing system will simply be built upon in a next major system 
revision. Therefore, the team removed this from the Medium risk areas and moved it to 
Low risk. 

For both systems, the Documentation input is very high due to rigorous DoD 
standards and requirements, and the Number and Diversity of Platforms is Extra high due 
to the wide range of potential users the database will be accessed by. These two factors 
combined may cause major issues for system programmers, builders and integrators. As a 
result this is a major risk area for both systems. 

Tables 13 and 14 summarize the medium and low risks for each system, as well as 
the risk mitigation suggestions from Expert COSYSMO. 





Risk Mitigation Strategy from 

Risk 

Level 

Input 1 

Input 2 

Constructive Systems 
Engineering Cost Model 




(COSYSMO) 


Documentation 
= Very High 

Diversity of 
Platforms = 

Extra High 

Not applicable 


Service 

Diversity of 

Understand baseline functionality 


Requirements 

Platforms = 

better and how it changes across 

c n 

2 

S 

# =3 

QJ 

= High 

Extra High 

installations/platforms 

Level of 

Service 

Stakeholder 

Tpam 

Put people with experience working 

S 

Requirements 
= High 

= Very Low 

together to meet the high ‘illities 


Level of 

Service 

Documentation 

Extensive documentation to support 


Requirements 
= High 

= Very High 

traceability for high interoperability 

X 

C/2 

2 

£ 

Migration 

Diversity of 

Limit legacy system involvement, 

Complexity = 

Platforms = 

reduce the number of interfaces by 

© 

- 

High 

Extra High 

defining a common interface 
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Risk 

Level 

Input 1 

Input 2 

Risk Mitigation Strategy from 
Constructive Systems 
Engineering Cost Model 
(COSYSMO) 


Technology 

Risk = 

Nominal 

Diversity of 
Platforms = 

Extra High 

Early identification of potential 
installations, upfront effort 
including prototyping to cover each 
installation 

Migration 
Complexity = 
High 

Stakeholder 

Team Cohesion 
= Very Low 

Enable legacy system 
communication among team 

Migration 
Complexity = 
High 

Documentation 
= Very High 

Find old documents and people to 
translate them, seek analogous 
documentation and learn from it, 
reverse-engineer old system 

Technology 
Risk = 

Nominal 

Stakeholder 

Team Cohesion 
= Very Low 

Rigorous enforcement of gate 
criteria early, increased 
coordination and frequency of 
communication 

Technology 

Risk = 

Nominal 

Documentation 
= Very High 

Prototype, modeling and 
simulation, trade studies 

Documentation 
= Very High 

Multisite 
Coordination = 
Nominal 

Not applicable 

Documentation 
= Very High 

# of Recursive 
Levels in Design 
= Nominal 

Not applicable 


Table 13. Risk Associated with Improving ESDS 
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Risk 

Level 

Input 1 

Input 2 

Risk Mitigation Strategy from 
Constructive Systems Engineering 
Cost Model (COSYSMO) 


Documentation 
= Very High 

Stakeholder 

Team Cohesion = 
Very Low 

Not applicable 

c n 

2 

Level of 

Service 
Requirements 
= High 

Diversity of 
Platforms = Extra 
High 

Understand baseline functionality 
better and how it changes across 
installations/platforms 

s 

5 

§ 

Level of 

Service 
Requirements 
= High 

Stakeholder 

Team Cohesion 
Very Low 

Put people with experience working 
together to meet the high ‘illities 


Level of 

Service 
Requirements 
= High 

Documentation = 
Very High 

Extensive documentation to support 
traceability for high interoperability 


Technology 

Risk = 

Nominal 

Diversity of 
Platforms = Extra 
High 

Early identification of potential 
installations, upfront effort including 
prototyping to cover each installation 


Migration 
Complexity = 
Nominal 

Diversity of 
Platforms = Extra 
High 

Limit legacy system involvement, 
reduce the number of interfaces by 
defining a common interface 

Low Risk 

Architecture 
Understanding 
= Nominal 

Diversity of 
Platforms = Extra 
High 

Prototyping, much testing 


Technology 

Risk = 

Nominal 

Stakeholder 

Team Cohesion = 
Very Low 

Rigorous enforcement of gate criteria 
early, increased coordination and 
frequency of communication 


Architecture 
Understanding 
= Nominal 

Stakeholder 

Team Cohesion 
Very Low 

Setup system level IPT’s with 
customers, involve customers early, 
prioritize requirements 


115 






Risk 

Level 

Input 1 

Input 2 

Risk Mitigation Strategy from 
Constructive Systems Engineering 
Cost Model (COSYSMO) 


Technology 
Risk = 

Nominal 

Documentation = 
Very High 

Prototype, modeling and simulation, 
trade studies 

Documentation 
= Very High 

Multisite 
Coordination = 
Nominal 

To Be Determined (TBD) 

Documentation 
= Very High 

# of Recursive 
Levels in the 
Design 

Nominal 

TBD 

Documentation 
= Very High 

Process 

Capability = 
Nominal 

Subcontract, hire or partner with 
high process domain expertise 

Documentation 
= Very High 

Personnel/Team 
Capability = 
Nominal 

TBD 

Architecture 
Understanding 
= Nominal 

Documentation = 
Very High 

Do more documentation 


Table 14. Risk Associated with Building a New System 


J. SUMMARY 

The purpose of the requirements analysis was to translate stakeholder needs into a 
set of system operational requirements and maintenance and support concepts. Functional 
analysis was then conducted to identify the system resources that would be required for 
DAS to achieve the operational concept that was developed from the requirements 
analysis. Using the results of the requirements analysis and functional analysis, the team 
conducted an AoA to find the best alternative that would achieve DAS capabilities the 
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stakeholders need. To do this, a number of alternatives were identified. The team 
determined that the most effective alternatives were to either build a brand new system, 
or to modify and improve an existing system to meet the needs of the stakeholders. Due 
to the number of existing Distance Support systems that currently exist, the team had to 
reduce the number of possible systems. The team defined a number of evaluation 
measures and metrics so each system’s performance could be assessed based on their 
current capabilities. Stakeholders were asked to complete a swing weight matrix to 
determine their preference weight for each requirement. Then three QFD HOQs were 
used to reduce the number of possible existing systems to four. A gap analysis was 
performed to determine that the existing system with the least amount of functional gaps 
was ESDS. Cost Analysis was conducted using COSYSMO to compare the two 
alternatives, either 1) modify ESDS (ESDS+) or 2) build a new system. The results 
showed that ESDS+ would cost 60% less than building a new system. Thus, if the SE 
hourly cost was estimated to be $50 per hour, ESDS+ would cost $680,000 and the new 
system would cost $2,064,000 to develop. From Risk Analysis, Expert COSYSMO 
showed that ESDS+ had less risk issues. Expert COSYSMO evaluated the total risk 
exposure points of ESDS+ as 44.7 and the new system as 45.7. 
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IV. SYSTEM ARCHITECTURE DESIGN 


The third step in the SE process was to develop the system architecture of DAS. 
To do this, first the team defined the requirements which translated from the 
stakeholder’s needs then traced the requirements to the system functions, allocated the 
functions to the components and established all the relationships between the functions 
and components. The team utilized Vitech’s CORE® software suite to document the 
functional architecture and the analysis as discussed in Chapter 111. Then, DoDAF 
products were created to describe the DAS architecture in the graphical and tabular 
presentation. The team used the DAS architecture to instantiate the ESDS+ architecture, 
which would be based on augmenting the current ESDS architecture. 

A. ARCHITECTURAL DEVELOPMENT APPROACH 

The system architecture was developed using a top-down functional 
decomposition and allocation approach. According to Buede, 

The functional architecture of a system contains a hierarchical model of 
the functions performed by the system, the system’s components, and the 
system configuration items; the flow of informational and physical items 
from outside the system through the transformational processes of the 
system’s functions and on to the waiting external systems being serviced 
by the system; a data model of the system’s items; and a tracing of 
input/output requirements to both the system’s functions and items (Buede 
2009,211). 

IDEFO was used as the graphical process modeling technique to represent the 
functional architecture of the DAS. IDEFO modeling was chosen because IDEFO has 
well-defined, standardized syntax and semantics that distinguish between the inputs to be 
transformed into outputs and the control information that guides the transformation 
process. In addition, the IDEFO is capable of representing the physical architecture, 
namely the mechanism within IDEFO (Buede 2009). Specific IDEFO modeling details can 
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be found in the 2009 National Institute of Standards and Technology, Integration 
Definition for Function Modeling (IDEFO). An example of IDEFO syntax is shown in 
Figure 45. 

The primary elements of IDEFO diagrams captured within this document are 
summarized as follows: 

• Function-a transformation of inputs to outputs, by means of some 
mechanism, and subject to certain controls, that is identified by a function 
name and modeled by a box 

• Box-a rectangle containing a verb or verb phase and representing a 
function in a diagram 

• Input-represents what is transformed or consumed by the function to 
produce the function’s output 

• Control-represents conditions that must be met before the function can 
produce correct output; used as the stimulus for the response (e.g. tasking, 
orders, requests) 

• Output-represents what is produced by the function 

• Mechanism-represents the mechanism for the function or in other words, 
the means to carry out the function. 
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Input 

User input Data 
Ship Data 

Fleet Support Infrastructure Data Base 


Control 


K 


Network Interface Connection 
Internet Access 


V.i.o 




■3 




Mechanism 


T 


Provide External 
Interface 


(NMCI) 
Network Provider 



Output 


Systems and POCs Info 

“ ') Assist Data 
i Data 
tistics Data 
Data 


Figure 45. IDEFO Syntax Example 

The methodology for developing the architecture followed a hierarchal approach. 
DoDAF products were used extensively throughout the development of the DAS 
architecture. DoDAF is widely used by organizations developing system solutions for the 
DoD. From the Architecture Framework Version 2.0, Volume 1: Introduction, Overview, 
and Concepts, Managers Guide, DoDAF V2.0 is defined as the “overarching, 
comprehensive framework and conceptual model enabling the development of 
architectures to facilitate the ability of DoD managers at all levels make key decisions 
more effectively” (DoD 2009, 2). Since this project’s SE process would not follow the 
entire V-shaped pattern of the 2009 DoD SE Model, not every DoDAF product was 
created for this project. The DoDAF products created were limited to the Operational and 
System Views and only the products that were applicable to the DAS architecture and 
within the scope of the capstone project. All other DoDAF products were deferred to 
future work. As illustrated in Figure 46, all of the Operational Views (OV), including: 1) 
Operational View (OV-1), 2) Operational Node Connectivity View (OV-2), 3) 
Operational Activity View (OV-5), and 4) Operational Event Trace Description (OV-6c), 
were developed during the stakeholder requirement definition phase. The System Views 
(SV) shown in Figure 46, including: 1) System Interface Description (SV-1), 2) System 
Resource Flow Description (SV-2), 3) System Functionality Description (SV-4), and 4) 
Operational Activity to System Function Traceability Matrix (SV-5a), were generated to 

facilitate the requirements analysis and architecture design. 
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Figure 46. DoDAF Products Development Mapped to SE Process 


The DoDAF products were built based on the sequence depicted in Figure 47. The 
build sequence was derived from “DoDAF Architecture Framework, Example Build 
Process” by Don Muehlbach, Ph.D. Each view builds on previous views and can result in 
the refinement of prior views as the architecture matures. The OV-l illustrates the high 
level operational view of USN surface fleet conducting Distance Support in which the 
DAS is considered a subsystem of the overall Distance Support System of Systems (SoS). 
The OV-5 depicts and decomposes the DAS operational activities necessary to support 
that mission. The OV-2 shows the connections and information flows among various 
entities (nodes) needed to execute those activities. The OV-6c reveals the time sequence 
of the decomposed activities. The SV-5a maps the decomposed operational activities to 
system functions (and, by extension, to systems). The SV-4 shows the connections and 
information flows among the system functions. The SV-l describes interfaces required 
among systems to perform assigned functions. The SV-2 specifies the system resource 
flows between the systems. 
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Figure 47. 


DoDAF Products Build Sequence 


Table 15 provides the product name and a brief definition of all the DoDAF views that 
were developed and documented as the architecture artifacts for this project. 
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Department of 
Defense 
Architecture 
Framework 
(DoDAF) 
Product 

DoDAF Product 
Name 

General Description 

OV-1 

High Level 
Operational 

Concept Graphic 

High level graphical/textual description of 
operational concept 

OV-2 

Operational Node 

Connectivity 

Description 

Operational nodes, connectivity, and 
information exchange need lines between 
nodes 

OV-5 

Operational 

Activity Model 

Capabilities, operational activities, 
relationships among activities, inputs, and 
outputs, overlays can show cost, performing 
nodes, or other pertinent information 

OV-6c 

Operational Event 
Trace Description 

One of the three products used to describe 
operational activity - identifies business 
rules that constrain operation 

SV-1 

Systems Interface 
Description 

Identification of system nodes, systems, and 
system items and their connections, within 
and between nodes 

SV-2 

Systems 

Communications 

Description 

System nodes, systems, and system items, 
and their related communication lay-down 

SV-4 

Systems 

Functionality 

Description 

Functions performed by systems and the 
system data flows among system functions 

SV-5a 

Operational 

Activity to Systems 
Function 

Traceability Matrix 

Mapping of systems back to capabilities or 
of system functions back to operational 
activities 


Table 15. DoDAF Products Description 
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B. OPERATIONAL ARCHITECTURE 

1. Operational View (OV-1) 

The DAS will be used as a Distance Support tool in a collaborative secured 
environment where the data will be accessed and shared by multiple entities including 
ships at sea and shore based support infrastructure. Figure 48 illustrates the high level 
concept of operation of the DAS hosted by NSWC PHD where ships communicate with 
shore based infrastructure via satellite communication (SATCOM) in real time or near 
real time as parts of Distance Support with respect to six different functions of Distance 
Support as indicated at the bottom of the diagram. 


125 




Figure 48. Distance Support Operational View (OV-1) 
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2. Operational Nodes Connectivity (OV-2) 

The Operational Nodes Connectivity as shown in Figure 49 illustrates the data 
required for aggregation in support of Distance Support are exchanged between the DAS 
located at NSWC PHD to the external nodes through a series of existing unclassified and 
classified networks, a level of interconnectivity currently employed by the Navy today. 
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Figure 49. Operational Nodes Connectivity (OV-2) 
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3. 


External Interface 


The external interface between the DAS and other systems and/or databases, 
where the maintenance and logistics data is generated by the ship, will be collected by 
DAS through multiple data sources residing in different organizations. The new data 
exchange is illustrated in dotted arrows in Figure 50 while the solid arrows indicated the 
current process that is executed in the Navy support infrastructure today. 



Figure 50. DAS External Interface Diagram 
4. Operational Activities (OV-5) 

The next step in the architectural development phase was the creation of the 
Operational Activity Model (OV-5) shown in Figures 51 and 52. Due to the size of 
Figure 51, Figure 52 was provided to show an enlarged figure focused on the Analyze 
Data, Disseminate Self Help Corrective Maintenance Data, and Disseminate RMA 
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Trends Data blocks. This approach decomposed all of the functions into their component 
operations. The OV-5 system was modeled using the IDEFO format to better illustrate the 
flow of key elements necessary for the system to accomplish its mission. The main 
activities are: 1) Establish Network Connection, 2) Collect Data, 3) Process Data, 4) 
Analyze Data, 5) Disseminate Self Help Corrective Maintenance Data and 6) 
Disseminate RMA Trends Data. Each activity consists of nodes that have input, output, 
control, and mechanism flows going into and out of each node. 


130 



Network Connection 


Fleet Data 

Fleet Support Infrastructure Data 
User Input Data 


Establish Network 
Connection 


Internet Access 


Fleet Tr aining Dat j 


Fleet RfMA Data 
Fle eflMi intenana 
“Fiiet .opisbcs Dal 


O 

Network Provider 


Analyze Data 


System Pi 
LRUH l g h 


"Co n mr EcMPrr ent F ailure s 


Perform ince 
Failure Itenr 
Data 


Disseminate Self 
Help Corrective 
Maintenance Data 


Metv^rk 

)( 


■cheAjler 

irk C bnnection A 


3 0 


Disseminate RMA 
Trends Data 


Display Troubleshooting Procedures for Common Equipment Failures 
— Display Corrective Maintenance Data 
—^ Dispaly Tech Support Info 
Display Logistics Data 


£ Display RMA/Trends Data 
i Display Fleet Training Deficiency Data 
5 Display Fleet Readiness Data 
5 Display Fleet Cost Data 


TO 

System Developer 


Figure 51. Operational Activities (OV-5) 
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Figure 52. Enlarged Operational Activities (OV-5) 
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The first node is to “Establish Network Connection” (A. 1.0). This allows the DAS 
to connect and aggregate data from other fleet support infrastructure systems and/or 
databases by an Internet connection provided by network providers such as NMCI or 
Navy Information Technology for the 21 st Century (IT-21). After the network co nn ection 
is established, the data (fleet data, fleet support infrastructure data, and user input data) 
will be collected via the “Collect Data” node (A.2.0) either automatically (scheduled) or 
manually (from the user interface). The “Collect Data” node will filter the data into 
different categories such as 1) fleet training data, 2) fleet RMA data, 3) fleet maintenance 
data, and 4) fleet logistics data. The collected data is then sent to the “Process Data” 
(A.3.0) node for refinement. The fourth node is “Analyze Data” (A.4.0). At this node, all 
the data will be analyzed to generate multiple end products such as 1) System 
Performance Metrics, 2) Corrective Maintenance Solution, 3) Predictive Trends Analysis, 
and 4) Life Cycle Cost Metrics that will be sent to the “Disseminate Self Help Corrective 
Maintenance Data” (A.5.0) node and the “Disseminate RMA Trends Data” (A.6.0) node 
to make the data available for the stakeholder access either in the form of a report or a 
display on NSWC PHD web pages. 

5. Operational Event Trace Description (OV-6c) 

The Operational Event Trace Description (OV-6c) is a graphical method of 
describing the operational activities or functions that are performed by the operational 
nodes through a scenario or a sequence of events with respect to time. As depicted in 
Figure 53, the event starts with the “Establish Network Interface” function, which is 
performed automatically by all the nodes through a series of Navy enterprise network 
connections including Navy IT-21 and NMCI. After the connections are established, the 
data from the fleet and fleet support infrastructure databases are sent to DAS though the 
external functions “Distribute Ship Data” and “Distribute Fleet Support Data” (the 
analysis of these functions are not within scope of this project). The next events are 
executed by the functions within DAS that include: 1) “Obtain Data,” 2) “Process Data,” 
3) “Analyze Data,” 4) “Report Data,” 5) “Display Data,” and 6) “Print and Save Data.” 
After the data is aggregated, processed, and analyzed, the output data will be made 
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available through the NSWC PHD Portal for the ships and stakeholders to get access via 
the “Access Data” function. (The “Access Data” function is not covered in this report 
due to the limited scope of this project). 
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Figure 53. Operational Event Trace Description (OV-6c) 
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C. FUNCTIONAL ARCHITECTURE 

1. System Functionality Description (SV-4) 

In continuation of the architectural development phase, the DAS Functionality 
Description (SV-4) was created as shown in Figure 54. The goal of the SV-4 was to 
specify the functional decomposition the data flows among the functions that the DAS 
must perform. As defined in DoDAF V2.0 Volume 2, Architecture Data and Model, 
Architect’s Guide, which is dated 28 May 2009, the purposes of the SV-4 are to “develop 
a clear description of the necessary data flows that are input (consumed) by and output 
(produced) by each resource, to ensure that the functional connectivity is complete, and 
to ensure that the functional decomposition reaches and appropriate level of detail” (DoD 
2009, 206). The focus of the SV-4 was on the functions themselves and the order in 
which they occur. It was necessary to create a SV-4 since a system’s functions drive its 
architecture, or in other words, form follows function. In addition to providing a deeper 
understanding of what functions DAS must perform, the SV-4 fed input data into other 
architectural products such as the functional allocation matrices and the SV-5a. DoDAF 
does not specify what functional modeling language must be used for the SV-4. A top 
down approach was used to create the SV-4 diagram which each “swim lane” lies across 
horizontally in the diagram representing the high level system functions. The SV-4 was 
created within the context of the OV-1, OV-5, and system boundary diagram. The 
functions included in the SV-4 needed to allow the DAS to meet the mission described by 
the OV-1. They also needed to be aligned to some operational activity within the OV-5. 
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Figure 54. System Functionality Description (SV-4) 
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2. System View of Operational Activity to Systems Function Traceability 
Matrix (SV-5a) 

The Operational Activity to System Function Traceability Matrix (SV-5a) 
identifies activities and the associated system functions required by DAS to perform the 
activities successful. The SV-5a relates system functions from the SV-4 to the operational 
activities from the OV-5. The SV-5a illustrates how the system functions support DAS 
capability, thus identifying the transformation of an operational need into a purposeful 
action performed by DAS. Figure 55 shows the mapping between an operational activity 
and a system function denoted by a dot to assess the status of the system function. 
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Figure 55. System View of Operational Activity to System Function (SV-5a) 
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D. PHYSICAL ARCHITECTURE 


1. System Interface Description (SV-1) 

As defined in DoDAF V.2.0, the system interface description (SV-1) addressed 
the composition and interaction of systems. The SV-1 links together the operational and 
systems architecture models by depicting how resources are structure and interact to 
realize the logical architecture specified in an OV-2. Figure 56 depicts the composition 
and interactions of the DAS with other systems as previously defined in OV-1 and OV-2. 
DAS will connect to other systems via a Transmission Control Protocol/Intemet Protocol 
(TCP/IP). 



Figure 56. System Interface Description (SV-1) 
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2. System Resource Flow Description (SV-2) 

The system resource flow description identifies the systems flow between systems 
as shown in Figure 57. The interfaces between DAS and other systems are comprised of 
internal and external interfaces. The internal interface is defined the interactions of the 
systems within NSWC PHD physical boundary. DAS interfaces with other NSWC PHD 
systems for display and data storage through and an unclassified NMCI network. Even 
though the scope of the project was only focus on unclassified data, it is considered that 
the classified network topology and system interface are considered very similar to 
unclassified environment. 



Figure 57. System Resource Flow Description (SV-2) 
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E. ESDS+ ARCHITECTURE 


Based on the results from the AoA previously addressed in Chapter III Section J, 
it is recommended that modifying ESDS will be a better solution than developing a new 
system based on the gap analysis, cost analysis and risk analysis that was performed. This 
section defines the augmented architecture of ESDS+, or the extent of the system 
architecture modifications that must occur to the existing ESDS, in order to meet all the 
functional architecture of DAS. In this report, the functions that require modifications 
and/or additions will be referred to as augmented functions. The approach of defining the 
ESDS+ architecture was based on the gap analysis between the existing ESDS and DAS 
functional requirements. As previously defined, the five high level functions, as shown in 
Figure 58, that are required additions for ESDS+ are: 1) obtain data from fleet, 2) process 
general information, 3) process training data, 4) display fleet support data and 5) display 
corrective maintenance data. 
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Modified ESDS Augmented Functions 
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In order to expand the ESDS+ architecture in further detail, each defined 
augmented function was decomposed to the lower level function. An IDEFO diagram was 
created to show how the inputs are converted to outputs among the functions. The 
following paragraphs and figures will address ESDS+’s functional decomposition with its 
respective IDEFO diagram. It is important to note that ESDS was designed and developed 
as an engineering and supportability analysis tool rather than a Distance Support tool 
(NSWC PHD 2009); therefore all functional gaps are mainly associated with fleet 
support. 

1. Obtain Data (F.2.0) 

ESDS currently does not collect data directly from the fleet. Stakeholders have 
expressed the need for DAS to collect remote assessment reports, ships’ system 
performance data, and technical assistance reports. Figure 59 shows the functional 
decomposition of the “Obtain Data from Fleet” function while Figure 60 shows the 
“Obtain Data from Fleet” functional interface diagram. 
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Figure 59. Augmented Functions Obtain Data (F.2.0) 
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Figure 60. Obtain Data From Fleet IDEFO (F.2.2) 
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2. Process Data (F.3.0) 

Another ESDS functional gap was processing general information. ESDS does 
not collect and process general information pertaining to SMEs point of contact, ship and 
system description, and system configuration for instance. Figure 61 shows the 
decomposed “Process General Information” function. The functions that would need to 
be added for ESDS+ are: 1) “Provide SME POC Information by Organization and 
System,” 2) “Provide System Information Based on a Hierarchy Structure,” 3) “Provide 
Frequently Asked Question Data” and 4) “Provide Blog and Forum Data.” The interface 
diagram is illustrated in Figure 62. Figure 63 shows the decomposed “Process Training 
Data” function. The augmented function is “Process Training Discrepancy Data.” 
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Figure 61. Augmented Functions Process Data (F.3.0) 
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3. Display Data (F.6.0) 

ESDS provides some information related to fleet historical data concerning 
logistics and RMA data that can be accessed via the NSWC PHD Portal. ESDS does not 
provide any information that can be used for self-help maintenance support, such as 1) a 
listing of SME point of contacts, 2) ship and system information, 3) troubleshooting tips, 
4) frequently asked questions, 5) equipment common failure items, nor 6) forums where 
Sailors and SMEs can share information related to equipment maintenance. Figures 64, 
65, and 66 illustrate the augmented functions for displaying data that are required for 
ESDS+. 
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Figure 64. Augmented Functions Display Data (F.6.0) 
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Figure 65. Display Fleet Support Information IDEFO (F.6.1) 
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Figure 66. Display Corrective Maintenance Information IDEFO (F.6.3) 


F. SUMMARY 

The last step of the SE process that the team completed was to develop the 
architecture for DAS and ESDS+. “The ultimate goal [of a system architecture] is the 
generation of information for decision makers to determine what the proposed systems 
are likely to do, to compare these systems with related current and proposed technology, 
and to acquire appropriate new technologies compatible or complementary with current 
capabilities” (Dam 2006, 1). The team used IDEFO to map how inputs are transformed 
into outputs and the controls that make it happen. The IDEFO was used to model both the 
functional and physical architectures of DAS. As a means of describing the DAS 
architecture, a number of DoDAF products were developed. The DoDAF products were 
tailored to this project and thus only a limited number of Operational Views and Systems 
Views were produced. The DoDAF Operational Views identify the tasks and activities 
that need to be accomplished as well as the operational elements required to complete the 
DAS’ mission. The DoDAF System Views depict the interconnections between software 
and hardware required for DAS to function. The architecture for ESDS+ was then 
developed based on the gap analysis that was discussed in Chapter III, the DoDAF 
products, and the IDEFO model developed for DAS. 
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V. CONCLUSION 


A. SUMMARY 

This capstone project addressed the need for a solution to improve the Navy’s 
current Distance Support capability, as the Navy and related stakeholders have 
determined that an improved Distance Support capability is necessary and will greatly 
benefit fleet readiness. In order to address the need for improved Distance Support, the 
team recommends the use of a DAS to aggregate and capture knowledge. Furthermore, 
the team recommends implementing the DAS by improving ESDS to provide additional 
functionality and significantly enhance self-help and otherwise improve Distance Support 
capabilities. The term “ESDS Plus” (ESDS+) has been adopted to distinguish between 
the current system and the preferred system. 

To guide the project, the team answered the following research questions, which 
were developed to frame the team’s research effort: 

• Why is improving the Navy’s Distance Support system important or 
necessary? 

• How do others conduct Distance Support and are they effective? 

• How do the stakeholders define an effective and affordable Distance 
Support system? 

• How can the existing Distance Support system be improved or modified to 
increase fleet readiness and reduce TOC? 

1. Why is improving the Navy’s Distance Support system important or 
necessary? 

This research question was important because the answers were used to develop 
the following problem statement: 

In recent years, the Navy’s decision to reduce manning and training with 

the increased complexity of combat systems as new programs emerge 
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have led to a decline in Sailors’ ability to operate, maintain, and sustain 
combat systems to the levels required to meet mission readiness 
requirements (Balisle 2011). Numerous Distance Support tools currently 
used to respond to USN fleet combat system issues are often slow and 
ineffective. The eventual technical solutions are often not captured for 
knowledge retention and reutilization, nor are they available as a self-help 
tool for the war-fighters. Knowledge data that is captured is difficult to 
access and utilize in a timely manner. In addition, current Distance 
Support tools used by Subject Matter Experts (SME) to obtain and analyze 
system performance metrics are manually intensive and limited in 
capability. 

This problem statement can be broken down into the following four sub-problems. 

a. Current Distance Support Tools are often Slow and Ineffective 

The stakeholders indicated that increasing the Distance Support capability 
has become even more important as budgets are constrained. The combat system 
personnel aboard USN ships are tasked to have their equipment in a mission-ready state 
at all times when deployed. Diagnostics on these complex systems can be lengthy, as can 
the typical trouble call for help from the shore-based technical support infrastructure. To 
improve the Distance Support process and to avoid unnecessary system down time from 
waiting for technical assistance from shore support, Sailors can quickly and easily search 
and obtain maintenance information via ESDS+ without having to contact the SME. 

b. Technical Solutions are often not Captured nor Available to the 
Fleet 

Previous NSWC PHD Distance Support studies and already completed 
surveys revealed that most technical issues are being responded to on a case by case basis 
in manner that is dependent upon the assigned SME’s knowledge of the system. Any 
solutions discovered may not be recorded for a technical community forum to be used by 
other end users. ESDS+ will address this problem by collecting data directly from the 
fleet and displaying the data in clear and concise reports. The ability to extract and 
display information automatically could significantly increase Sailors’ ability conduct 
maintenance using a self-help tool. Some examples of the topics that would be available 
are 1) a listing of SME points of contact, 2) ship and system information, 3) 
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troubleshooting tips, 4) frequently asked questions, 5) equipment common failure items, 
or 6) forums where Sailors and SMEs can share information related to equipment 
maintenance. 


c. Captured Data is Difficult to Access and Utilize 

Presently, NSWC PHD is providing Distance Support utilizing tools such 
as prognostics and remote monitoring, but the methodology used is based on what was 
developed for individual systems, meaning the content and tools are hosted on system- 
exclusive servers. For Sailors to gain access to the data, special permission is typically 
required. As a data aggregator, ESDS+ would interface with all of the existing Distance 
Support tools so data could be readily available and accessed efficiently by all Sailors and 
SMEs. Also, by augmenting the five ESDS functions, the users would be able to obtain 
more informative reports that are user-friendly. 

d. Current Distance Support Tools are Manually Intensive and 
Limited in Capability 

When SMEs assist Sailors in troubleshooting efforts, the primary vehicle 
of communication is usually e-mail. Thus, Sailors are required to manually provide all 
metrics to the SMEs. This leads to limits in capability, as well as creates room for errors 
and miscommunication. ESDS+ would automatically obtain data such as ships’ system 
performance and trending analysis data directly from the fleet, which would eliminate the 
need to manually enter data to obtain help. 

2. How do others conduct Distance Support and are they effective? 

This capstone project examined other organizations to learn if they experience the 
same problems NSWC PHD does with respect to Distance Support, and how they judge 
success. With regards to USN Distance Support, the focus is fixing a deployed asset. If a 
ship cannot perform a particular mission, the ship itself most likely cannot be replaced 
quickly, ft is because of this paradigm that knowledge is not captured from events and the 
Distance Support system does not currently meet the goals of the stakeholders. 
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3 . 


How do the stakeholders define an effective and affordable Distance 
Support system? 


The team applied an SE approach to clearly define the architecture that would be 
an effective and affordable Distance Support system. The team started by consulting past 
NSWC PHD Distance Support surveys and studies to clearly define needs. The result of 
the analysis showed that NSWC PHD needed to improve Distance Support data 
aggregation and knowledge reutilization capabilities in order to provide more effective 
Distance Support to the fleet. To do this, the needs analysis suggested that the solution 
needed to be easily accessible, provide high quality information that was current, 
relevant, accurate, reliable and complete, the data should be well organized and displayed 
and/or reported as needed. These needs were used to develop a CONOP (at a very high 
level), to identify the stakeholders, and to determine how the stakeholders would 
communicate with their system provided as a solution. After completion of the initial 
research, the team scoped the project to the data aggregation process, which was named 
DAS, to ensure the project could be completed within the time allowed since the data 
aggregation process itself is quite complex and software intensive. 

Once the needs were defined, a requirements analysis was conducted to identify 
the operational, functional, physical and performance requirements of the DAS. The 
requirements fell into three major categories: 1) Characteristics, 2) Design and 
Construction, and 3) Component Level requirements. Together, these requirements could 
be used to translate the stakeholders’ needs into a set of system operational, maintenance 
and support concepts. The team used Vitech’s CORE® software suite to input the DAS 
requirements, beginning the development of the DAS architecture. DAS functions were 
then identified. The functions were: Provide External Interface, Obtain Data, Process 
Data, Analyze Data, Report Data, Display Data, and Print and Save Data. The functions 
were traced to the DAS requirements and design criteria. This tracing helped identify the 
necessary resources required for DAS support and operation. 

The team solicited preferences from stakeholders in order to prioritize and further 
define the system requirements and system functions. By focusing on higher level data 
integration system requirements and functions, the team conducted an AoA to identify 
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alternatives and this included modifying existing systems that could satisfy all system 
requirements. Unfortunately, the team was unable to identify an existing system that 
could meet all requirements, which meant that some development would be required. To 
minimize development, the team conducted a gap analysis of the existing systems, and 
determined that among the possible alternatives, ESDS contained the least number of 
functional gaps. 

Since cost was a critical determining factor, the team compared the cost of 
ESDS+ to building an entirely new system. The team focused the cost analysis on 
development costs of the two alternatives, as it was determined that life cycle costs, 
disposal costs, and savings would be relatively similar between both options. COSYSMO 
2.0 software was used to estimate and compare the engineering effort that would be 
required to develop ESDS+ or a brand new system. The cost analysis revealed that 
ESDS+ was the less expensive solution, estimating that the development effort of ESDS+ 
would cost approximately 40% of the total development cost required to build a new 
system. To further analyze the two alternatives, Expert COSYSMO was used to conduct 
a cost risk analysis. On a scale of zero to 702, the results showed that ESDS+ had a risk 
level of 44.7 and the new system had a risk level of 45.7, which shows that both 
alternatives are equally risky. 

4. How can the existing Distance Support system(s) be improved or 
modified to increase fleet readiness and reduce total ownership costs? 

Based on the team’s analysis, ESDS+ was therefore recommended as the 
preferred alternative. This turned out to be good news, because a significant amount of 
resources have already been invested in developing ESDS. ESDS is currently in use at 
the NSWC PHD Command, but only on a limited basis. By adding self-help and other 
missing functionality to ESDS, Distance Support capabilities will be significantly 
enhanced. 
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ESDS+ is the recommended solution because it also answers the team’s problem 
statement, which was used to structure this study. ESDS+ seeks to be a user-friendly 
efficient tool that will capture knowledge through multiple available data sources for 
maintenance, performance and logistics that could be utilized in a timely manner to make 
Distance Support a more responsive and effective product. 

B. AREAS FOR FUTURE RESEARCH 

There are many more opportunities to continue improving the USN Distance 
Support capability, further the development and implementation of the DAS, and 
examine the other many components of the overall function of providing Distance 
Support. For future work, the team recommends that the user interface function of the 
DAS be expanded to increase the usability of the aggregated data. In addition, the 
following list provides examples of areas that need further research and development, and 
could be conducted in other capstone projects at NPS: 

• Complete development, testing, and evaluation of the ESDS+ 

• Expand on the user interface function 

• Improve the content and quality of the data sources 

• Improve knowledge capturing systems, methods, and techniques 

• Measure and improve data access times 

• Improve connectivity to the DAS, especially while deployed 

• Expand the DAS beyond maintenance to include areas such as training, 
logistics, personnel, and mission readiness 

• Expand the DAS to included classified information sharing 
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• Conduct unlimited analysis of the data produced by the DAS to increase 
effectiveness and efficiencies related to producing, operating, and 
maintaining Navy weapons systems and related functions, i.e., improve 
equipment reliability and increase operational availability 

• Refine the DAS architecture. 

Finally, the team strongly encourages the stakeholders to go forward with the planning 
and budgeting to develop ESDS+ as the recommended solution for improving Distance 
Support and enabling the fleet to maintain the highest state of mission readiness while 
minimizing TOC. 
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APPENDIX A. SYSTEM REQUIREMENTS 


The Table 16 lists all requirements the Distance Support team derived from past 
Distance Support studies. 


Number 

Name 

Description 

R.0.0 

Data Aggregation System 

(DAS) Specific 

Requirements 

The system shall display status on installed 

engineering alterations and engineering 

alterations under development or planned for 

development 

R.1.0 

Characteristics 

The system shall display status on installed 

engineering alterations and engineering 

alterations under development or planned for 

development 

R.1.1 

Performance 

The system shall display status on installed 

engineering alterations and engineering 

alterations under development or planned for 

development 

R.l.1.1 

External Interface 

This system shall be capable of interface 

with other systems including human 

interface and databases to collect and provide 

necessary data to perform all the functions. 

R.1.1.1.1 

System Interface 

The system shall have the capability to 

interface with other systems and databases 

within fleet support infrastructure to 

aggregate the data 
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Number 

Name 

Description 

R.l.1.1.2 

User Interface 

The system shall be accessible via Port 

Hueneme Division (PHD) Portal 

R.l.1.2 

Fleet Maintenance 

Support Data and Metrics 

Group Title 

R.l.1.2.1 

Display a list of 

system/subsystem on each 

platform 

The system shall provide a list of 

system/subsystem on each platform 

R. 1.1.2.2 

Display Subject Matter 

Expert (SME) contact 

information for each 

system/ subsystem 

The system shall display SME contact 

information for each system/subsystem 

R. 1.1.2.3 

Display a list of Open 

Casualty Reports 

(CASREP), Trouble 

Tickets, and Help Desk 

items open for a specific 

ship or an entire Strike 

Group 

The system shall display a list of Open 

CASREP, Trouble Tickets, and Help Desk 

items open for a specific ship or an entire 

Strike Group 

R.l.1.2.3.1 

Search and Display 

CASREP data based on 

category, ship, element, 

system subsystem, 

symptom, status 

The system shall be able to search and 

display the CASREP data based on category, 

ship, element, system subsystem, symptom, 

and status 
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Number 

Name 

Description 

R. 1.1.2.4 

Display Area of 

Responsibility (AOR) 

requirements/Standing 

Orders (Classified) for all 

platform in a Strike Group 

The system shall display AOR 

requirements/Standing Orders (Classified) 

for all platform in a Strike Group 

R. 1.1.2.5 

Display outstanding/open 

CASREP, 2-Kilo, and 

Technical Assist Visit 

Request 

The system shall display outstanding/open 

CASREP, 2-Kilo, and Technical Assist Visit 

Request 

R. 1.1.2.6 

Display Technical Assist 

Visit Reports (TAVRs) by 

system 

The system shall display TAVRs by system 

R. 1.1.2.7 

Display the past and 

current In-Service 

Engineering Agent (ISEA) 

investigations at the 

systems, equipment, and 

Lowest Replaceable Unit 

(LRU) levels 

The system shall display the past and current 

ISEA investigations at the systems, 

equipment, and LRU levels 

R. 1.1.2.8 

Display status on installed 

engineering alterations 

and engineering 

alterations under 

development or planned 

for development 

The system shall display status on installed 

engineering alterations and engineering 

alterations under development or planned for 

development 

R. 1.1.2.9 

Display unclassified 

CASREP metrics 

The system shall display unclassified 

CASREP metrics 


165 




Number 

Name 

Description 

R.l. 1.2.10 

Display known problems 

(issues seen by other 

Ships) and frequently 

asked questions 

The system shall display known problems 

(issues seen by other Ships) and frequently 

asked questions 

R.l.1.2.11 

Display lessons learned 

and past 

troubleshooting/problem 

resolution information 

The system shall display lessons learned and 

past troubleshooting/problem resolution 

information 

R.l.1.2.12 

Display authorized 

detailed troubleshooting 

procedures for common 

equipment failures 

The system shall display authorized detailed 

troubleshooting procedures for common 

equipment failures 

R.l.1.2.13 

Display Command Issues 

Management (CIM) 

information (status) 

The system shall display CIM information 

(status) 

R.l.1.2.14 

Display a ship’s combat 

system software 

configuration (including 

the software version of 

each sub-system) 

The system shall display a ship’s combat 

system software configuration (including the 

software version of each sub-system) 
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Number 

Name 

Description 

R.l.1.2.15 

Display Board of 

Inspection and Survey 

(INSURY) and 

Availability schedules and 

type, for instance Selected 

Restricted Availability 

(SRA), Docking or Dry¬ 
docking Selected 

Restricted Availability 

(DSRA), or Regular 

Overhaul (ROH), for ships 

and provide a graphical 

representation of the 

INSURV and Availability 

schedules of an entire 

Strike Group 

The system shall display INSURV and 

Availability schedules and type like SRA, 

DSRA, and ROH for ships and provide a 

graphical representation of the INSURV and 

Availability schedules of an entire Strike 

Group 

R.l.1.2.16 

Display common 

equipment failures and 

corrective action taken per 

element/system/subsystem 

/components 

The system shall display common equipment 

failures and corrective action taken per 

element/system/subsystem/components 

R.l.1.2.17 

Display a user-selectable 

range of the top 

equipment taking the 

longest time to repair 

The system shall display a user-selectable 

range of the top equipment taking the longest 

time to repair 
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Number 

Name 

Description 

R.l.1.2.18 

Display a user-selectable 

range of the top LRUs 

with the highest failure 

rates for equipment in a 

Pareto diagram for 

specific systems 

The system shall display a user-selectable 

range of the top LRUs with the highest 

failure rates for equipment in a Pareto 

diagram for specific systems 

R.l.1.2.19 

Display (using a Pareto 

diagram) a user-selectable 

range of the top high- 

usage rate LRUs for 

specific systems 

The system shall display (using a Pareto 

diagram) a user-selectable range of the top 

high-usage rate LRUs for specific systems 

R. 1.1.2.20 

Display manning level per 

work center per ship 

The system shall display manning level per 

work center per ship 

R.l.1.2.21 

Display manning 

qualification to conduct 

mission per work center 

per ship per mission 

The system shall display manning 

qualification to conduct mission per work 

center per ship per mission 

R. 1.1.2.22 

Display performance 

trends per 

element/system/subsystem 

The system shall display performance trends 

per element/system/subsystem 

R. 1.1.2.23 

Display maintenance work 

hours at the 

ship/system/cabinet/LRU 

level 

The system shall display maintenance work 

hours at the ship/system/cabinet/LRU level 

R. 1.1.2.24 

Display past and current 

technical assistance efforts 

requested by the fleet 

The system shall display past and current 

technical assistance efforts requested by the 

fleet 
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Number 

Name 

Description 

R. 1.1.2.25 

Correlate Preventive 

Maintenance (PMS) 

history with material 

readiness or equipment 

failures and display the 

results 

The system shall correlate PMS history with 

material readiness or equipment failures and 

display the results 

R. 1.1.2.26 

Display the composition 

(unclassified) and planned 

deployment dates 

(Classified) for current 

and future Strike Groups 

and others deployed as 

identified by the Fleet 

Commanders 

The system shall display the composition 

(unclassified) and planned deployment dates 

(Classified) for current and future Strike 

Groups and others deployed as identified by 

the Fleet Commanders 

R. 1.1.2.27 

Display Combat System 

(CS) Safety Issues per 

Ship and historical/trends 

data 

The system shall display CS Safety Issues 

per Ship and historical/trends data 

R. 1.1.2.28 

Display current 

configuration and past 

configurations up to 5 

years by ship by system 

The system shall display current 

configuration and past configurations up to 5 

years by ship by system 

R. 1.1.2.29 

Display an average time- 

open bar chart for 2-Kilo 

The system shall display an average time- 

open bar chart for 2-Kilo 
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Number 

Name 

Description 

R. 1.1.2.30 

Display Mean Time To 

Repair (MTTR) metrics 

using data from 2-Kilo 

Maintenance Man Hours 

(MMH) and repair time 

information 

The system shall display MTTR metrics 

using data from 2-Kilo MMH and repair time 

information 

R.l.1.2.31 

Display MTTR Data from 

Material Readiness 

Database (MRDB) 

The system shall display MTTR Data from 

MRDB 

R. 1.1.2.32 

Display Mean Time 

Between Equipment 

Mission Critical Events 

(MTB(EMCE)) and Mean 

Time Between Equipment 

Malfunction Events 

(MTB(EME)) or obtain 

and display data from 

MRDB 

The system shall display MTB (EMCE) and 

MTB(EME) or obtain and display data from 

MRDB 

R.l. 1.3 

Logistics Data 

Group Title 

R.l.1.3.1 

Display Allowance Part 

List (APL) of all systems 

The system shall display APL of all systems 

R.l.1.3.2 

Display a user-selectable 

range of the normalized 

top LRU with the highest 

cost by system-year or 

cabinet-year 

The system shall display a user-selectable 

range of the normalized top LRU with the 

highest cost by system-year or cabinet-year 
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Number 

Name 

Description 

R.l.1.3.3 

Provide high demand and 

high cost parts per 

element/system/subsystem 

/LRU 

The system shall generate and display high 

demand and high cost parts per 

element/system 

R.l.1.3.4 

Provide ship class and 

ship baseline Cost Report 

The system shall generate and display cost 

reports based on ship class, ship baseline, 

and individual ship 

R.l.1.3.5 

Provide Cost Reports 

based on 

system/ subsystem 

The system shall generate and display Cost 

Reports for each system/subsystem 

R.l.1.3.6 

Compare and display 

Mean Logistics Delay 

Time (MLDT) for any 

LRU at ship/system level 

The system shall display the comparison 

chart of MLDT for any LRU at ship/system 

level where data is available 

R.l.1.3.7 

Display parts that have 

failed in the past quarter 

above a specified 

threshold in three 

categories 

The system shall display parts that have 

failed in the past quarter above a specified 

threshold in three categories 

R.l.1.3.8 

Display technical 

publications (bulletins) 

developed by shore 

support activities, such as 

ISEA and Regional 

Maintenance Center 

(RMC) 

The system shall display technical 

publications (bulletins) developed by shore 

support activities, such as ISEA and RMC 
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Number 

Name 

Description 

R.l. 1.3.9 

Display the number of 

failures of LRUs at the 

ship baselines, and class 

levels 

The system shall display the number of 

failures of LRUs at the ship baselines, and 

class levels 

R. 1.1.3.10 

Display supply inventory, 

sparing info, for any user- 

specified part by National 

Item Identification 

Number (NUN) 

The system shall display supply inventory, 

sparing info, for any user-specified part by 

NUN 

R.l.1.3.11 

Display Diminishing 

Manufacturing Sources 

(DMS) data by 

system/ equipment/LRU 

The system shall display DMS data by 

system/equipment/LRU 

R.l.1.3.12 

Display part numbers and 

part’s usage based on 

historical data 

The system shall display part numbers and 

its usage based on historical data for the last 

5 years 

R.l. 1.4 

Training Data 

Group Title. 

R.l.1.4.1 

Display Training 

Discrepancies from Ship 

Reports, Technical Assist 

Visit Report, On-Site 

Training Report, trip 

report, and Availability 

report 

The system shall display Training 

Discrepancies from Ship Reports, Technical 

Assist Visit Report, On-Site Training Report, 

trip report, and Availability report 

R. 1.1.4.2 

Display training 

deficiencies CASREP, 

and 2-Kilo reports 

The system shall display training 

deficiencies from CASREP and 2-Kilo 

reports 
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Number 

Name 

Description 

R.l.1.5 

Reliability, 

Maintainability, and 

Availability (RMA) 

Analysis Data 

Group Title 

R.l. 1.5.1 

Display RMA drivers 

from individual ship, ship 

baseline, Strike Group, 

and Warfare-Area levels 

The system shall display RMA drivers from 

individual ship, ship baseline, Strike Group, 

and Warfare-Area levels 

R.l. 1.5.2 

Display an assessment of 

system/ subsystem 

performance 

The system shall collect data from ship 

readiness reporting such as Maintenance 

Figure of Merit (MFOM) and Operational 

Readiness Test System Tech Assist Remote 

Support (ORTSTARS) to assess and display 

the status of system/subsystem with 

Red/Yellow/Green indicators based on 

system/subsystem specifications or user- 

defined threshold 

R.l.1.5.3 

Display Operational 

Availability (Ao), Mean 

Time Between Failure 

(MTBF), and Mean Down 

Time (MDT) data per ship 

baseline 

The system shall display Ao, MTBF, and 

MDT data per ship baseline 

R. 1.1.5.4 

Display unclassified and 

classified MFOM 

indicators 

The system shall display unclassified and 

classified MFOM indicators 
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Number 

Name 

Description 

R.l.1.6 

Reports 

The system shall be designed to allow the 

user to generate, save, and print the reports to 

a file with the standard format such as 

Acrobat Portable Document Format (PDF) or 

Microsoft® Office (Word, Excel) from the 

web pages where the data can be selected 

and filtered by user defined 

R.1.2 

Physical Characteristics 

Group Title 

R. 1.2.1 

Human System 

Integration 

The system shall be designed and tested to 

satisfy human engineering design 

requirements and standards included in but 

not limited to the latest version of MIL-STD- 

1472F. 

R. 1.2.2 

Size 

The major components that are selected for 

the system shall support rack mount 

installation 

R.1.3 

Reliability 

The system shall be designed with 

redundancy capability which is capable of 

supporting the Ao of 90% 

R.1.4 

Maintainability 

The system shall be designed to support 

hardware and software maintenance where 

MTTR is less than 1 hour and the completed 

reload will take no more than 20 minutes. 

R.1.5 

Environment Condition 

The system shall be designed to operate in a 

normal laboratory environment conditions. 

R.2.0 

Design and Construction 

Group Title 
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Number 

Name 

Description 

R.2.1 

Data Collection 

The system shall be designed to collect data 

either by manually enter data from user 

interface or data push/pull from external file 

or database 

R.2.2 

Data Reporting 

The system shall be designed to generate and 

display data as specified in section 1.1 

R.2.3 

Navy Marine Corps 

Intranet (NMCI) 

Compliance 

The system shall be designed to comply with 

NMCI 

R.2.4 

Print and Save 

The system shall have the capability to Print 

and Save the data 

R.3.0 

Component Level 

Requirements 

Group Title 

R.3.1 

Hardware 

The system shall use Commercial Off-the- 

Shelf (COTS) hardware that capable to 

support the design characteristics defined in 

section 1.0 

R.3.2 

Software 

The system shall use COTS software that 

capable to support the design characteristics 

defined in section 1.0 


Table 16. System Requirements 
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APPENDIX B. SYSTEM FUNCTIONS 


This section documents the system functions artifacts that were developed and 
generated from CORE®. Table 17 provides a list of all system functions that were 
derived from the requirements analysis. Figures 67, 68, 69, 70, 71, and 72 show DAS 
functional hierarchy in greater detail. Figures 73, 74, 75, 76, 77, and 78 illustrate DAS 
functional IDEFO diagrams. Figure 79 shows the mapping requirements to system 
functions analysis results, and Table 18 lists all of the data exchanges that occur between 
all of the DAS functions. 


Number 

Name 

Description 

F.O 

Provide Data Aggregation 
Capability 

Group Title. The capability of aggregating data 
from numerous existing Distance Support 
sources, exporting data to the fleet to promote 
self-help, and exporting data to help facilitate 
trend/failure analysis opportunities. 

F.1.0 

Provide External Interface 

Group Title. Provide communication with the 
external systems. 

F.1.1 

Execute System Interface 

Establish network connection 

F.2.0 

Obtain Data 

Group Title. Obtain data from the external 
systems. 

F.2.1 

Obtain Data from User 

Inputs 

Users input data into system database and web 
pages 

F.2.1.1 

Receive Data via Web Form 

Data is entered by user via a Web Form 

F.2.1.2 

Import and Format Data 
Entered by User 

User enter data directly into the system either 
by using a form or a spreadsheet 

F.2.2 

Obtain Data from Fleet 

Recorded System Performance Data is 
downloaded from ship either manually or 
automatic. 
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F.2.2.1 

Import Data from Remote 
Assessment Report 

Import data from Assessment Report 

F.2.2.2 

Extract Data from Ship’s 

Data Recording 

Extract data from data recording transferred 
from ship to shore via SIPRNET 

F.2.2.3 

Import Fleet Tech Assist 

Data 

Obtain Tech Assist Data from the following 
database: Command Issues Management 
(CIM), Global Distance Support Center 
(GDSC) Remedy, Trip Report, and SIPRNET 
CHAT 

F.2.2.4 

Import Fleet Data from On- 
Site Assessment 

Import Data from the Board of Inspection and 
Survey (INSURV) or Chief of Naval 

Operations (CNO) Availability 

F.2.3 

Obtain Data from Fleet 
Support Infrastructure 

Data is collected through the Fleet Support 
Infrastructure database: Sailor To Engineer 
(S2E), GDSC Remedy, CIM, Aegis Combat 
System Reliability Maintainability and 
Supportability Database (ACSRMS), Aegis 
Configuration Control and Engineering Status 
System (ACCESS), Maintenance Figure of 
Merit (MFOM), Material Readiness Database 
(MRDB), NAVSEA Logistics Center (NSLC) 
Maintenance and Material Management (3M), 
Federal Logistics Data (FEDLOG), 
Configuration Data Managers Database-Open 
Architecture (CDMD-OA), and so on 

F.2.3.1 

Collect Fleet Maintenance 
Data 

Collect Ship’s Report Maintenance Data 

F.2.3.1.1 

Import Fleet Maintenance 
Action Data 

Collect data from 3M database 

F.2.3.2 

Collect Fleet Logistics Data 

Collect fleet logistics data such as part usages, 
part inventory, and requisition information. 

F.2.3.2.1 

Import Parts/Supplies Data 

Import parts/supplies data from NSLC and 

Naval Supply Systems Command (NAVSUP) 

F.2.3.2.2 

Import Parts Inventory Data 

Import parts inventory data 
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F.2.3.3 

Collect Fleet Training 
Discrepancy Data 

Collect fleet personnel training discrepancy 
data 

F.2.3.4 

Collect Fleet Reliability, 
Maintainability, and 
Availability (RMA) Data 

Collect fleet RMA data 

F.3.0 

Process Data 

Group Title. Process collected data. 

F.3.1 

Process General 

Information 

Process and Filter the data into different 
categories. 

F.3.1.1 

Provide Subject Matter 
Expert (SME) Point of 
Contact (POC) info by 
Organization/System 

Provide a list of the SME POCs filtered by 
systems that they support and by organization 
(i.e., John Smith, NSWC PHD, SPY-1A 
RADAR,john.smith@navy.mil, (805) 228- 
1234) 

F.3.1.2 

Provide system info based 
on hierarchy structure 

Listing the system information based on 
hierarchy structure below: 

-Platform (i.e., CG/DDG or DDG1000) 

-Segment (i.e., Combat System, Hull, 
Mechanical and Electrical (HM&E), 

Command, Control, or Communications, 
Computers & Intelligence (C4I)) 

-Element (i.e., SPY, Command and Decision 
(C&D), Weapon Control System (WCS), 

Engine, or Navigation) 

-System (i.e., Transmitter, Power Generator, or 
Display) 

-Subsystem 

-Component 

F.3.1.3 

Provide Frequent Ask 
Question (FAQ) Data 

Provide FAQ Data 

F.3.1.4 

Provide Blog and Forum 

Data 

Provide Blog and Forum Data shared by fleet 
personnel and fleet support agents 

F.3.2 

Process Maintenance Data 

Process, filter, and categorize the maintenance 
data 

F.3.3 

Process Logistics Data 

Process, filter, and categorize the logistics data 
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F.3.4 

Process Training Data 

Process, filter, and categorize the training data 

F.3.5 

Process RMA Data 

Process, filter, and categorize the RMA data 

F.4.0 

Analyze Data 

Group Title. Analyzing and updating the data 

F.4.1 

Analyze Maintenance Data 

Analyze the maintenance data 

F.4.2 

Conduct System 

Performance Trending 
Analysis 

Analyze and conduct the system performance 
trending Analysis 

F.4.3 

Compute System 

Operational Availability 
(Ao)/Inherent Availability 
(Ai) based on RMA Data 

Analyze and compute the system Aq/A, based 
on the RMA data 

F.4.4 

Conduct Cost Analysis 

Conduct Cost Analysis 

F.5.0 

Report Data 

Group Title. Generate Reports 

F.5.1 

Generate System 

Assessment Report 

Generate reports based on the data collected 
from Tech Assists, remote monitoring, or 
system assessment. The system will have the 
ability to generate the assessment reports either 
by automatically or manually 

F.5.2 

Generate Logistics Report 

Generate reports that associated with logistics 
such as supplies inventories, Part Usages, and 
high cost failure items 

F.5.3 

Generate System Status 
Report 

Generate reports based on the ship’s reported 
system status 

F.5.4 

Generate System RMA 
Report 

Generate reports based on RMA analysis, such 
as Ao, Mean Time Between Failures (MTBF), 
and Mean Time To Repair ( MTTR) 

F.6.0 

Display Data 

Group Title. Display data via NSWC PHD 
WebPages 
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F.6.1 

Display Fleet Support 
Information 

Display in website the following general 
information: In-Service Engineering Agent 
(ISEA) POCs (names, phone number, e-mail) - 
Hierarchical structure system information 
based on ship class, element (Combat System 
(CS), C4I, HM&E) 

F.6.1.1 

Display FAQ, Blog and 
Forum data 

Display consolidated data relative to FAQ, 

Blog, and Forum posted by fleet personnel and 
fleet support agents 

F.6.1.2 

Display SME POC Info 

Display SME POCs 

F.6.1.3 

Display Ship and System 

Info 

Display ship and system information 

F.6.2 

Display Historical Fleet 

Data 

Display historical Fleet data including the 
information below: 

-Number of Casualty Report (CASREP) per 
ship per year 

-Current Open and Closed CASREP 

F.6.3 

Display Corrective 
Maintenance Information 

Display information to assist ship force to 
conduct corrective maintenance based on 
system/equipment hierarchy. Data include 
Questions and Answers (Q&A), 

Troubleshooting tips, and Common equipment 
failure symptom 

F.6.3.1 

Display Historical System 
Maintenance Action 

Display information pertaining historical 
system maintenance actions 

F.6.4 

Display Logistics 

Information 

Display information related to Logistics based 
on system hierarchy. Data include Tech 

Manual Bibliography, Maintenance Index Page 
(MIP)/Preventive Maintenance (PMS) listing, 
Allowance Part List (APL), Allowance 
Equipment List (AEL) Listing, On-Board 

Spares list, and Links to download Tech 

Manual. 

F.6.5 

Display RMA Analysis 

Data 

Display information related to Reliability, 
Maintainability, and Availability of each 
system on each ship. Data include System Aq. 
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F.7.0 

Print & Save 

Print and Save Data performed by 



Stakeholders. 


Table 17. System Functions 


hier Provide External... 


7 


F.1.0 

Provide External 
Interface 


Function 


F.L1 


Execute System 
Interface 


Function 


Project: 

Organiz... 

Date: 

Distance... 

NSWC ... 

Decemb... 


Figure 67. Provide External Function (F.1.0) 


hier Obtain Data 


j 



Project: 

Organization: 

Date: 

Distance Support Data Aggre... 

NSWC PHD 

December 2S F 2012 


Figure 68. Obtain Data Functions (F.2.0) 
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Figure 69. Process Data Functions (F.3.0) 


hier Analyze Data 




Project: 

Distance Support Data Aggregation System 

Organization: 

NSWC PHD 

Date: 

December 26, 2012 




Figure 70. Analyze Data Functions (F.4.0) 


hier Report Data 


7 



Project: 

Organization: 

Date: 

Distance Support Data Aggregation System 

NSWC PHD 

December 26, 2012 


Figure 71. Report Data Functions (F.5.0) 
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Figure 72. Display Data Functions (F.6.0) 


Network Interface Connection 




Internet Access 


User Enter Data 
Ship Data 

Fleet Support Infrastructure Data Base 



+ Fleet 3M Data 
+ Fleet Logistics Data 
> Fleet Maintenance Support Data 
* Fleet RMA Data 

Ships., Systems and POCs Info 


() 

Operation System 
Data Aggregation System 


Figure 73. Provide External Interface IDEFO (F.1.0) 
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Ships., Systems and POCs Info 


Fleet Maintenance Support Data 


Fleet RMA Data 
Fleet Logistics Data 
Fleet 3M Data 



MS SQL Server 


Data Aggregation System 


Figure 74. Obtain Data IDEFO (F.2.0) 
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Figure 75. Process Data IDEFO (F.3.0) 
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Figure 78. Display Data IDEFO (F.6.0) 
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R.l.1.2.8 

Display status on installed engineering alterations and 
engineering alterations under development or planned for 
development 


• 

• 


• 


• 


• 


• 













• 






R.l. 1.2.9 

Display unclassified CASREP metrics 


• 

• 


• 


• 


• 

• 

• 

• 


• 

• 

• 

• 







• 

• 

• 

• 

• 


R.l.1.2.10 

Display known problems (issues seen by other Ships) and 
frequently asked questions 


• 

• 


• 


• 


• 

• 

• 

• 


• 

• 

• 

• 







• 

• 

• 

• 



R.l. 1.2.11 

Display lessons learned and past troubleshooting/problem 
resolution information 


• 

• 


• 


• 


• 

• 




• 

• 









• 






R.l.1.2.12 

Display authorized detailed troubleshooting procedures for 
common equipment failures 


• 

• 


• 




• 















• 






R.l.1.2.13 

Display CIM information (status) 


• 

• 




• 


• 





• 










• 






R.l.1.2.14 

Display a ship's combat system software configuration 
(including the software version of each sub-system) 


• 

• 


• 


• 


• 















• 






R.l.1.2.15 

Display INSURV and Availability schedules and type (SRA, 
DSRA, RCOH, etc.) for ships and provide a graphical 
representation of the INSURV and Availability schedules of 
an entire Strike Group 


• 

• 


• 


• 


• 















• 






R.l.1.2.16 

Display common equipment failures and corrective action 
taken per element/system/subsystem/components 


• 

• 


• 


• 


• 

• 




• 










• 

• 

• 

• 



R.l.1.2.17 

Display a user-selectable range of the top equipment taking 
the longest time to repair 


• 

• 


• 


• 


• 

• 




• 

• 









• 

• 

• 

• 



R.l.1.2.18 

Display a user-selectable range of the top LRUs with the 
highest failure rates for equipment in a Pareto diagram for 
specific systems 


• 

• 


• 


• 


• 

• 





• 

• 








• 

• 

• 

• 

• 


R.l.1.2.19 

Display (using a Pareto diagram) a user-selectable range of 
the top high-usage rate LRUs for specific systems 


• 

• 


• 


• 


• 

• 

• 













• 

• 

• 

• 

• 


R.l. 1.2.20 

Display manning level perwork center pership 


• 

• 




• 


• 















• 
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R.l. 1.2.21 

Display manning qualification to conduct mission per work 
center pership per mission 


• 

• 




• 


• 



• 












• 






R.l. 1.2.22 

Display performance trends per element/system/subsystem 


• 

• 




• 


• 

• 





• 

• 








• 

• 

• 


• 


R.l. 1.2.23 

Display maintenance work hours at the 
ship/system/cabinet/LRU level 


• 

• 




• 


• 

• 




• 










• 

• 

• 




R.l. 1.2.24 

Display past and current technical assistance efforts 
requested by the Fleet 


• 

• 


• 


• 


• 

• 




• 










• 

• 

• 




R.l. 1.2.25 

Correlate PMS history with material readiness or equipment 
failures and display the results 


• 

• 




• 


• 





• 

• 









• 

• 





R.l. 1.2.26 

Display the composition (unclassified) and planned 
deployment dates (Classified) for current and future Strike 
Groups and other deployers identified by Fleet Commanders 


• 

• 




• 


• 















• 






R.l. 1.2.27 

Display CS Safety Issues per Ship and historical/trends data 


• 

• 




• 


• 















• 






R.l. 1.2.28 

Display current configuration and past configurations up to 5 
years by ship by system 


• 

• 


• 


• 


• 















• 

• 





R.l.1.2.29 

Display an average time-open bar chart for 2-Kilos 


• 

• 




• 


• 















• 

• 



• 


R.l. 1.2.30 

Display Mean Time To Repair (MTTR) metrics using data from 
2-Kilo Maintenance Man Hours (MMH) and repair time 
information 


• 

• 




• 


• 

• 




• 










• 




• 


R.l. 1.2.31 

Display Mean Time To Repair (MTTR) Data from MRDB 


• 

• 




• 


• 

• 




• 










• 

• 



• 


R.l. 1.2.32 

Display Mean Time Between Equipment Mission Critical 
Events (MTB(EMCE)) and Mean Time Between Equipment 
Malfunction Events (MTB(EME)) or obtain and display data 
from MRDB 


• 

• 




• 


• 

• 




• 

• 

• 














R.l. 1.3 

Logistics Data 






























R.l.1.3.1 

Display Allowance Part List (APL) of all systems 


• 

• 


• 


• 


• 















• 






R.l.1.3.2 

Display a user-selectable range of the normalized top 

Lowest Replaceable Unit (LRU) with the highest cost by 
system-year or cabinet-year 


• 

• 




• 


• 

• 

• 



• 



• 



• 




• 

• 


• 
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R.l.1.3.3 

Provide high demand and high cost parts per 
element/system/subsystem/LRU 


• 

• 




• 


• 

• 

• 






• 













R.l. 1.3.4 

Provide ship class and ship baseline Cost Report 


• 

• 




• 


• 


• 






• 



• 




• 



• 



R.l.1.3.5 

Provide Cost Reports based on system/subsystem 


• 

• 




• 


• 


• 






• 



• 




• 



• 



R.l.1.3.6 

Compare and display Mean Logistics Delay Time (MLDT) for 
any LRU at ship/system level 


• 

• 




• 


• 


• 













• 



• 



R.l.1.3.7 

Display parts that have failed in the past quarter above a 
specified threshold in three categories 


• 

• 


• 


• 


• 


• 




• 









• 

• 


• 



R.l.1.3.8 

Display technical publications (bulletins) developed by 
shore support activities, such as ISEA and RMC 


• 

• 


• 


• 


• 















• 






R.l. 1.3.9 

Display the number of failures of LRUs at the ship baselines, 
and class levels 


• 

• 




• 


• 


• 









• 




• 

• 


• 



R.l.1.3.10 

Display supply inventory, sparing info, for any user-specified 
part by NIIN 


• 

• 


• 


• 


• 


• 









• 




• 



• 



R.l. 1.3.11 

Display DMS data by system/equipment/IRU 


• 

• 


• 


• 


• 


• 









• 




• 



• 



R.l.1.3.12 

Display part numbers and part's usage based on historical 
data 


• 

• 




• 


• 


• 









• 




• 

• 


• 



R.l. 1.4 

Training Data 






























R.l. 1.4.1 

Display Training Discrepancies from Ship Reports, Tech Assist 
Visit Report, On-Site Training Report, trip report, Availability 
report 


• 

• 




• 


• 

• 

• 

• 


• 










• 






R.l. 1.4.2 

Display training deficiencies from Casualty Reports 
(CASREP), 2-kilo reports 


• 

• 




• 


• 





• 










• 






R.l. 1.5 

RMA Analysis Data 






























R.l.1.5.1 

Display reliability, maintainability, and availability drivers 
from individual ship, ship baseline, Strike Group and 
Warfare-Area levels 


• 

• 




• 


• 

• 

• 



• 

• 

• 



• 

• 

• 

• 


• 

• 


• 

• 


R.l.1.5.2 

Display an assessment of system/subsystem performance 


• 

• 


• 


• 


• 

• 

• 



• 

• 

• 



• 

• 

• 

• 


• 

• 

• 

• 

• 


R.l.1.5.3 

Display Operational Availability (Ao), Mean Time Between 
Failure (MTBF), & Mean Down Time (MDT) data per ship 
baseline 


• 

• 




• 


• 

• 

• 

• 


• 

• 

• 



• 

• 

• 

• 


• 

• 


• 

• 
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R.l. 1.5.4 

Display unclassified and clssified Maintenance Figure of 

Merit (MFOM) indicators 


• 

• 




• 


• 

• 

• 



• 

• 

• 








• 




• 


R.1.1.6 

Reports 


• 

• 




• 


• 

• 

• 

• 












• 





• 

R.l.2 

Physical Charateristics 






























R.1.2.1 

Human System Integration 






























R.1.3 

Reliability 






























R.1.4 

Maintainability 






























R.1.5 

Environment Condition 






























R.2.0 

Design and Construction 






























R.2.1 

Data Collection 






























R.2.2 

Accessible by authorized NMCI Users 






























R.2.3 

Data Reporting 






























R.2.4 

NMCI Compliance 






























R.3.0 

Component Level Requirements 






























R.3.1 

Hardware 






























R.3.2 

Software 































Figure 79. Mapping Requirements to System Functions 
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NAME 

DEFINITION 

INPUTTO 

OUTPUTTO 

TRIGGERS 

# of CASREP per Ship per Year 

Data relative to number of 
CASREP generated per 
ship peryear 

Function F.5.0 Report Data 
Function F.5.3 Generate System 
Status Report Function F.5.4 
Generate System RMA Report 
Function F.6.0 Display Data 
Function F.6.2 Display Historical 
Fleet Data 

Function F.4.0 Analyze Data Function 

F.4.2 Conduct System Performance 
Trending Analysis 


# of Issues per System per Year 

Data relative to number of 

equipment issues 
(anomalies) per system 
peryear 

Function F.5.0 Report Data 
Function F.5.3 Generate System 
Status Report Function F.5.4 
Generate System RMA Report 
Function F.6.0 Display Data 
Function F.6.2 Display Historical 
Fleet Data 

Function F.4.0Analyze Data Function 

F.4.2 Conduct System Performance 
Trending Analysis 


Access Data 

Data requested by 
stakeholders 


Function Ext.Func.3.0 Access Data 


As Needed 

Control line. Action is 

executed as needed only 



Function Ext.Func.3.0 Access Data 

Automatic 

Control line. Action is 

executed automatically 



Function F.O Provide Data Aggregation 

Capability Function F.2.0Obtain Data Function 

F.2.3 Obtain Data from Fleet Support 
Infrastructure Function F.2.3.1 Collect Fleet 

Maintenance Data Function F.2.3.2 Collect Fleet 

Logistics Data Function F.2.3.2.1 Import 
Parts/Supplies Data Function F.2.3.3 Collect 
FleetTraining Discrepancy Data Function F.2.3.4 
Collect Fleet RMA Data Function F.3.0 Process 

Data Function F.3.1 Process General Information 
Function F.3.1.1 Provide SME POC info by 
Organization/System Function F.3.1.2 Provide 
system info based on hierarchy structure 

Function F.3.1.3 Provide Frequent Ask Question 
Data Function F.3.1.4 Provide Blog and Forum 

Data Function F.3.2 Process Maintenance Data 

Function F.3.3 Process Logistics Data Function 
F.3.4 Process Training Data Function F.3.4.1 
Process Training Discrepancy Data Function F.3.5 
Process RMA Data Function F.4.0 Analyze Data 
Function F.4.1 Analyze Maintenance Data 
Function F.4.2 Conduct System Performance 
Trending Analysis Function F.4.3 Compute 

System Ao/Ai based on RMA data Function F.4.4 
Conduct Cost Analysis Function F.5.0 Report 

Data Function F.5.1 Generate System 

Assessment Report Function F.5.2 Generate 
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Blog and Forum Data 

Data is extracted from 

Blog and Forum shared by 
ship personnel and fleet 
support agents 

Function F.6.0 Display Data 
Function F.6.1 Display Fleet 
Support Information Function 

F.6.1.1 Display FAQ, Blog and 
Forum data 

Function F.3.0 Process Data Function 

F.3.1 Process General Information 
Function F.3.1.4 Provide Blog and Forum 

Data 


By Request 

Control line. Action is 

executed by request 



-- ------- 

Function Ext.Func.2.0 Collect and Disseminate 

Fleet Data Function Ext.Func.3.0 Access Data 
Function F.O Provide Data Aggregation 

Capability Function F.2.0Obtain Data Function 
F.2.2 Obtain Data from Fleet Function F.2.2.1 
Import Data from Remote Assessment Report 
Function F.2.2.4 Import Fleet Data from On-Site 
Assessment Function F.2.3 Obtain Data from 
Fleet Support Infrastructure Function F.2.3.1 
Collect Fleet Maintenance Data Function F.2.3.2 
Collect Fleet Logistics Data Function F.2.3.2.1 
Import Parts/Supplies Data Function F.2.3.3 
Collect Fleet Training Discrepancy Data Function 

F.2.3.4Collect Fleet RMA Data Function F.3.0 

Process Data Function F.3.1 Process General 

Information Function F.3.1.1 Provide SME POC 
info by Organization/System Function F.3.1.2 
Provide system info based on hierarchy 
structure Function F.3.1.3 Provide Frequent Ask 
Question Data Function F.3.1.4 Provide Blog and 

Forum Data Function F.3.2 Process Maintenance 

Data Function F.3.3 Process Logistics Data 
Function F.3.4 Process Training Data Function 

F.3.4.1 Process Training Discrepancy Data 

Function F.3.5 Process RMA Data Function F.4.1 

Analyze Maintenance Data Function F.4.2 
Conduct System Performance Trending Analysis 

CASREP Metrics 

Metrics relative to CASREP 

Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function 

F.5.3 Generate System Status 
Report Function F.5.4 Generate 
System RMA Report Function 

F.6.0 Display Data Function F.6.2 
Display Historical Fleet Data 

Function F.4.0 Analyze Data Function 

F.4.2 Conduct System Performance 
Trending Analysis 
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Common Equipment Failures 

Data relative to common 
equipmentfailures 

Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function 

F.5.2 Generate Logistics Report 
Function F.5.3 Generate System 
Status Report Function F.5.4 
Generate System RMA Report 
Function F.6.0 Display Data 
Function F.6.3 Display Corrective 
Maintenance Information 

Function F.6.3.1 Display Historical 
System Maintenance Action 

Function F.4.0 Analyze Data Function 

F.4.2 Conduct System Performance 
Trending Analysis 


Cost of Parts Replacement per 
system/ship/year 

Data relative to part 
replacement cost 
expenditures pership per 

year 

Function F.5.0 Report Data 
Function F.5.2 Generate Logistics 
Report Function F.5.3 Generate 
System Status Report Function 

F.6.0 Display Data Function F.6.4 
Display Logistics Information 

Function F.4.0Analyze Data Function 
F.4.4 Conduct Cost Analysis 


Cost Saving by using Distance 

Support 

Saving cost by using DS 

Function F.5.0 Report Data 
Function F.5.2 Generate Logistics 
Report Function F.5.3 Generate 
System Status Report Function 

F.6.0 Display Data Function F.6.2 
Display Historical Fleet Data 

Function F.4.0 Analyze Data Function 
F.4.4 Conduct Cost Analysis 


DMS Data 

Data relative to DMS 

Function F.5.0 Report Data 
Function F.5.2 Generate Logistics 
Report Function F.6.0 Display 

Data Function F.6.4 Display 
Logistics Information 

Function F.4.0 Analyze Data Function 

F.4.2 Conduct System Performance 
Trending Analysis 


FAQ Data 

Technical interchange 
data between ship 
personnel and fleet 
support agents 

Function F.6.0 Display Data 
Function F.6.1 Display Fleet 
Support Information Function 

F.6.1.1 Display FAQ, Blog and 

Forum data 

Function F.3.0 Process Data Function 

F.3.1 Process General Information 
Function F.3.1.3 Provide Frequent Ask 
Question Data 
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Fleet 3M Data 

Fleet 3M data provided by 
NSLC 

Function F.2.0 Obtain Data 

Function F.2.3 Obtain Data from 

Fleet Support Infrastructure 
Function F.2.3.1 Collect Fleet 

Maintenance Data Function 

F.2.3.2 Collect Fleet Logistics Data 
Function F.2.3.2.1 Import 
Parts/Supplies Data Function 

F.2.3.3 Collect Fleet Training 
Discrepancy Data 

Function F.1.0 Provide External 

Interface Function F.1.1 Execute System 
Interface 


Fleet Logistics Data 

Logistics data provided by 
NSLC/ NAVSUP 

Function F.2.0 Obtain Data 

Function F.2.3 Obtain Data from 

Fleet Support Infrastructure 
Function F.2.3.2 Collect Fleet 

Logistics Data Function F.2.3.2.1 
Import Parts/Supplies Data 
Function F.2.3.2.2 Import Parts 
Inventory Data 

Function F.1.0 Provide External 

Interface Function F.1.1 Execute System 
Interface 


Fleet Maintenance Support Data 

Data relative to fleet 

maintenance actions 

Function F.2.0 Obtain Data 

Function F.2.2 Obtain Data from 
Fleet Function F.2.2.1 Import 

Data from Remote Assessment 
Report Function F.2.2.2 Extract 
Data from Ship's Data Recording 
Function F.2.2.3 Import Fleet 

Tech Assist Data Function F.2.2.4 

Import Fleet Data from On-Site 

Assessment 

Function F.1.0 Provide External 

Interface Function F.1.1 Execute System 
Interface 


Fleet RMA Data 

Fleet historical data 

relative to RMA 

Function F.2.0 Obtain Data 

Function F.2.3 Obtain Data from 

Fleet Support Infrastructure 
Function F.2.3.4Collect Fleet 

RMA Data 

Function F.1.0 Provide External 

Interface Function F.1.1 Execute System 
Interface 


Fleet Support Infrastructure Data 

Base 

Data provided by fleet 
support infrastructure 

data base 

Function F.O Provide Data 
Aggregation Capability Function 
F.1.0 Provide External Interface 
Function F.1.1 Execute System 

Interface 

Function Ext.Func.2.0 Collect and 

Disseminate Fleet Data 
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Formatted Fleet Maintenance 

Support Data 

Maintenance Data 

provided by SME 

Function F.3.0 Process Data 

Function F.3.2 Process 

Maintenance Data Function F.3.3 

Process Logistics Data Function 
F.3.4 Process Training Data 
Function F.3.4.1 Process Training 
Discrepancy Data Function F.3.5 

Process RMA Data 

Function F.2.0 Obtain Data Function 

F.2.2 Obtain Data from Fleet Function 

F.2.2.1 Import Data from Remote 
Assessment Report Function F.2.2.2 
Extract Data from Ship's Data Recording 
Function F.2.2.3 Import Fleet Tech Assist 
Data Function F.2.2.4 Import Fleet Data 

from On-Site Assessment 


Formatted Fleet System 

Maintenance Data 

Maintenance Data from 

Fleet 

Function F.3.0 Process Data 

Function F.3.2 Process 

Maintenance Data Function F.3.3 

Process Logistics Data Function 
F.3.4 Process Training Data 
Function F.3.4.1 Process Training 
Discrepancy Data Function F.3.5 

Process RMA Data 

Function F.2.0 Obtain Data Function 

F.2.3 Obtain Data from Fleet Support 
Infrastructure Function F.2.3.1 Collect 

Fleet Maintenance Data Function F.2.3.3 
Collect Fleet Training Discrepancy Data 


Formatted General System 
Information Data 

Formatted general 
information relative to 
SMEs, ship information, 
system information 

Function F.3.0 Process Data 

Function F.3.1 Process General 

Information Function F.3.1.2 

Provide system info based on 
hierarchy structure Function 

F.3.1.3 Provide Frequent Ask 
Question Data Function F.3.1.4 
Provide Blog and Forum Data 
Function F.3.3 Process Logistics 

Data Function F.3.5 Process RMA 

Data 

Function F.2.0 Obtain Data Function 

F.2.1 Obtain Data from User Inputs 
Function F.2.1.1 Receive Data via Web 
Form Function F.2.1.2 Import and 

Format Data Entered by User 


Formatted Logistics Data 

Formatted data relative to 
logistics supply support, 
inventory 

Function F.3.0 Process Data 

Function F.3.3 Process Logistics 

Data Function F.3.5 Process RMA 

Data 

Function F.2.0 Obtain Data Function 

F.2.3 Obtain Data from Fleet Support 
Infrastructure Function F.2.3.2 Collect 
Fleet Logistics Data Function F.2.3.2.1 
Import Parts/Supplies Data Function 

F.2.3.2.2 Import Parts Inventory Data 


Formatted SME POC List 

Formatted data relative to 

SME POC Information 

Function F.3.0 Process Data 

Function F.3.1 Process General 

Information Function F.3.1.1 
Provide SME POC info by 
Organization/System 

Function F.2.0 Obtain Data Function 

F.2.1 Obtain Data from User Inputs 
Function F.2.1.1 Receive Data via Web 
Form Function F.2.1.2 Import and 

Format Data Entered by User 
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Formatted System Reliability Data 

Formatted data relative to 
ship system RMA 
information 

Function F.3.0 Process Data 

Function F.3.5 Process RMA Data 

Function F.2.0 Obtain Data Function 

F.2.3 Obtain Data from Fleet Support 
Infrastructure Function F.2.3.4Collect 

Fleet RMA Data 


Highest LRU Failures 

Information regarding LRU 
that has the highest 

failure rate 

Function F.5.0 Report Data 
Function F.5.2 Generate Logistics 
Report Function F.5.3 Generate 
System Status Report Function 
F.5.4 Generate System RMA 

Report Function F.6.0 Display 

Data Function F.6.2 Display 

Historical Fleet Data 

Function F.4.0 Analyze Data Function 

F.4.2 Conduct System Performance 
Trending Analysis 


Historical Maintenance Data 

Historical fleet 

maintenance data 

Function Ext.Func.4.0 Display 
Aggregation Data Function F.7.0 

Print & Save Data 

Function F.O Provide Data Aggregation 
Capability Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function F.5.3 
Generate System Status Report Function 
F.5.4 Generate System RMA Report 
Function F.6.0 Display Data Function 

F.6.2 Display Historical Fleet Data 
Function F.6.3 Display Corrective 
Maintenance Information Function 

F.6.3.1 Display Historical System 

Maintenance Action 


Historical System Performance 
Trends Data 

Historical data relative to 
system performance 
trends 

Function Ext.Func.4.0 Display 
Aggregation Data Function F.7.0 

Print & Save Data 

Function F.O Provide Data Aggregation 
Capability Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function F.5.3 
Generate System Status Report Function 
F.5.4 Generate System RMA Report 
Function F.6.0 Display Data Function 

F.6.2 Display Historical Fleet Data 
Function F.6.5 Display RMA Analysis 

Data 


Internet Access 

Control line. Action is 

executed when internet 

access becomes available 



Function F.1.0 Provide External Interface 

Function F.1.1 Execute System Interface 

Function F.3.1.4 Provide Blog and Forum Data 
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Known Equipment Problem 

Data relative to known 

equipment 

problem/failure 

Function F.5.0 Report Data 
Function F.5.3 Generate System 
Status Report Function F.5.4 
Generate System RMA Report 
Function F.6.0 Display Data 
Function F.6.3 Display Corrective 
Maintenance Information 

Function F.6.3.1 Display Historical 
System Maintenance Action 

Function F.4.0Analyze Data Function 
F.4.1Analyze Maintenance Data 


List of SME POC by System by 
Organization 

Data relative to SME POC 
information listed by 
organization 

Function F.6.0 Display Data 
Function F.6.1 Display Fleet 
Support Information Function 

F.6.1.2 Display SME POC Info 

Function F.3.0 Process Data Function 

F.3.1 Process General Information 

Function F.3.1.1 Provide SME POC info 
by Organization/System 


Logistics Cost Data 

Data relative to logistics 
supply cost 


Function F.6.0 Display Data Function 

F.6.2 Display Historical Fleet Data 
Function F.6.4 Display Logistics 
Information 


Logistics Data 

Data relative to Logistics 
supply, parts usage, cost, 
expenditures, etc... 


Function F.6.0 Display Data Function 

F.6.2 Display Historical Fleet Data 
Function F.6.4 Display Logistics 
Information 


Logistics Reports 

Reports contain logistics 
information such as parts 
usage, part cost, ship 
expenditures, LRU highest 
cost/expenditure, etc... 

Function Ext.Func.4.0Display 
Aggregation Data Function F.7.0 

Print & Save Data 

Function F.O Provide Data Aggregation 
Capability Function F.5.0 Report Data 
Function F.5.2 Generate Logistics Report 


Maintenance Cost Data 

Cost data relative to ship's 
equipment maintenance 


Function F.5.3 Generate System Status 
Report Function F.6.0 Display Data 
Function F.6.2 Display Historical Fleet 
Data Function F.6.4 Display Logistics 
Information 


Manning Level per Work Center per 
Ship 

Data relative to manning 
level pership perbaseline 

Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function 

F.5.2 Generate Logistics Report 
Function F.5.3 Generate System 
Status Report Function F.5.4 
Generate System RMA Report 
Function F.6.0 Display Data 
Function F.6.5 Display RMA 
Analysis Data 

Function F.4.0Analyze Data Function 
F.4.3 Compute System Ao/Ai based on 
RMA data 
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Manual 

Control line. Action is 

executed manually 



Function F.O Provide Data Aggregation 

Capability Function F.2.0 Obtain Data Function 
F.2.1 Obtain Data from User Inputs Function 
F.2.1.1 Receive Data via Web Form Function 

F.2.2 Obtain Data from Fleet Function F.2.2.1 
Import Data from Remote Assessment Report 
Function F.2.2.2 Extract Data from Ship's Data 
Recording Function F.2.2.3 Import Fleet Tech 
Assist Data Function F.2.2.4 Import Fleet Data 
from On-Site Assessment Function F.2.3 Obtain 
Data from Fleet Support Infrastructure Function 
F.2.3.1 Collect Fleet Maintenance Data Function 
F.2.3.2 Collect Fleet Logistics Data Function 

F.2.3.2.1 Import Parts/Supplies Data Function 
F.2.3.3 Collect FleetTraining Discrepancy Data 
Function F.2.3.4Collect Fleet RMA Data Function 

F.3.0 Process Data Function F.3.1 Process 

General Information Function F.3.1.1 Provide 

SME POC info by Organization/System Function 
F.3.1.2 Provide system info based on hierarchy 
structure Function F.3.1.3 Provide Frequent Ask 
Question Data Function F.3.2 Process 

Maintenance Data Function F.3.3 Process 

Logistics Data Function F.3.4 Process Training 

Data Function F.3.4.1 Process Training 
Discrepancy Data Function F.3.5 Process RMA 
Data Function F.4.0 Analyze Data Function F.4.1 

MTBF per System/Ship/Year 

Data relative to 
equipment/LRU MTBF per 
system pership peryear 

Function F.5.0 Report Data 
Function F.5.4 Generate System 
RMA Report Function F.6.0 

Display Data Function F.6.5 

Display RMA Analysis Data 

Function F.4.0 Analyze Data Function 
F.4.3 Compute System Ao/Ai based on 
RMA data 


MUR per System per year 

Data relative to MUR per 
system peryear 

Function F.5.0 Report Data 
Function F.5.4 Generate System 
RMA Report Function F.6.0 

Display Data Function F.6.5 

Display RMA Analysis Data 

Function F.4.0Analyze Data Function 
F.4.3 Compute System Ao/Ai based on 
RMA data 


Network Interface Connection 

Control line. Action is 

executed when network 

interface connection 

becomes available 



Function F. 1.0 Provide External Interface 

Function F.1.1 Execute System Interface 
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Periodic 

Control line. Action is 
executed periodically 



Function Ext.Func.1.0 Ship Sends Data to Shore 
Function Ext.Func.2.0 Collect and Disseminate 

Fleet Data Function F.O Provide Data 

Aggregation Capability Function F.2.0 Obtain 

Data Function F.2.3 Obtain Data from Fleet 
Support Infrastructure Function F.2.3.1 Collect 
Fleet Maintenance Data Function F.2.3.2 Collect 
Fleet Logistics Data Function F.2.3.2.1 Import 
Parts/Supplies Data Function F.2.3.3 Collect 

Fleet Training Discrepancy Data Function F.2.3.4 
Collect Fleet RMA Data Function F.3.0 Process 

Data Function F.3.5 Process RMA Data Function 

F.4.1 Analyze Maintenance Data Function F.4.2 
Conduct System Performance Trending Analysis 
Function F.4.3 Compute System Ao/Ai based on 
RMA data Function F.4.4 Conduct Cost Analysis 
Function F.6.0 Display Data Function F.6.2 

Display Historical Fleet Data Function F.6.4 
Display Logistics Information Function F.6.5 
Display RMA Analysis Data 

Print Reports 

Reports generated via 

Print 


Function F.O Provide Data Aggregation 
Capability Function F.7.0 Print & Save 

Data 


Processed Logistics Data 

Logistics data have already 
been processed 

Function F.4.0 Analyze Data 
Function F.4.3 Compute System 
Ao/Ai based on RMA data 

Function F.4.4 Conduct Cost 
Analysis 

Function F.3.0 Process Data Function 

F.3.3 Process Logistics Data 


Processed Maintenance Data 

Ship maintenance data 
have already been 
processed 

Function F.4.0 Analyze Data 
Function F.4.1Analyze 
Maintenance Data Function F.4.2 

Conduct System Performance 
Trending Analysis Function F.4.3 
Compute System Ao/Ai based on 
RMA data Function F.4.4 Conduct 
Cost Analysis 

Function F.3.0 Process Data Function 

F.3.2 Process Maintenance Data 


Processed Reliability Data 

Ship reliability data have 
already been processed 

Function F.4.0 Analyze Data 
Function F.4.2 Conduct System 
Performance Trending Analysis 
Function F.4.3 Compute System 
Ao/Ai based on RMA data 

Function F.4.4 Conduct Cost 
Analysis 

Function F.3.0 Process Data Function 

F.3.5 Process RMA Data 
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Processed Training Data 

Ship personnel training 
data have already been 
processed 

Function F.4.0 Analyze Data 
Function F.4.3 Compute System 
Ao/Ai based on RMA data 

Function F.4.4 Conduct Cost 
Analysis 

Function F.3.0 Process Data Function 

F.3.4 Process Training Data Function 

F.3.4.1 Process Training Descrepancy 

Data 


Q&A Data 

Data captured from Q&A, 
forum posted by ship 
personnel and fleet 
support agents 

Function Ext.Func.4.0 Display 
Aggregation Data 

Function F.O Provide Data Aggregation 
Capability Function F.6.0 Display Data 
Function F.6.1 Display Fleet Support 
Information Function F.6.1.1 Display 

FAQ, Blog and Forum data Function F.6.3 
Display Corrective Maintenance 
Information Function F.6.3.1 Display 
Historical System Maintenance Action 


RMA Data 

Data relative to ship RMA 


Function F.6.0 Display Data Function 

F.6.2 Display Historical Fleet Data 
Function F.6.5 Display RMA Analysis 

Data 


Safety Issue Related to 

Maintenance 

Data relative to safety 
isssue while performing 
equipment maintenance 

Function F.5.0 Report Data 
Function F.5.3 Generate System 
Status Report Function F.6.0 
Display Data Function F.6.2 

Display Historical Fleet Data 

Function F.4.0 Analyze Data Function 

F.4.1 Analyze Maintenance Data 


Ship and System Info 

Data relative to ship and 
system information 

Function F.6.0 Display Data 
Function F.6.1 Display Fleet 
Support Information Function 

F.6.1.3 Display Ship and System 
Info 

Function F.3.0 Process Data Function 

F.3.1 Process General Information 
Function F.3.1.2 Provide system info 
based on hieararchy structure 


Ship and System Information 

Ship Name System 
Nomenclature and 
Configuration (APL, Part 
Number) 


Function F.6.0 Display Data Function 

F.6.1 Display Fleet Support Information 
Function F.6.1.3 Display Ship and System 
Info Function F.6.4 Display Logistics 
Information 


Ship Data 

Ship data such as 
homeport, work centers, 
POCs, INMARSAT phone 
numbers, etc 

Function Ext.Func.2.0 Collect and 

Disseminate Fleet Data Function 
F.O Provide Data Aggregation 
Capability Function F.1.0 Provide 
External Interface Function F.1.1 

Execute System Interface 

Function Ext.Fund.0 Ship Sends Data to 

Shore 
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Ship force Training Discrepancies 
per Ship 

Data relative to ship force 
training discrepancies 
reported from tech assist, 
system assessment, and 
INSURVs, etc... 

Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function 

F.5.3 Generate System Status 
Report Function F.5.4 Generate 
System RMA Report Function 

F.6.0 Display Data Function F.6.5 
Display RMA Analysis Data 

Function F.4.0Analyze Data Function 
F.4.3 Compute System Ao/Ai based on 
RMA data 


Ships, Systems and POCs Info 

Data relative to ship, 
system, ship personnel 
POCs information 

Function F.2.0 Obtain Data 

Function F.2.1 Obtain Data from 

User Inputs Function F.2.1.1 

Receive Data via Web Form 
Function F.2.1.2 Import and 
Format Data Entered by User 

Function F.1.0 Provide External 

Interface Function F.1.1 Execute System 
Interface 


SME POCs Information 

Data relative to SME POCs 

information 


Function F.6.0 Display Data Function 

F.6.1 Display Fleet Support Information 
Function F.6.1.2 Display SME POC Info 


Supported Data 

Data relative to fleet 
support information 

Function Ext.Func.3.0 Access Data 

Function Ext.Func.4.0 Display 
Aggregation Data 


System Assessment Reports 

Reports generated from 
system assessment 
conducted by fleet 
support agents 

Function Ext.Func.4.0 Display 
Aggregation Data Function F.7.0 

Print & Save Data 

Function F.O Provide Data Aggregation 
Capability Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function F.5.3 
Generate System Status Report Function 
F.5.4 Generate System RMA Report 


System Availability to Support 
Warfare Area 

Data relative to system 
performance status that 
are required to support 
ship's mission 

Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function 

F.5.3 Generate System Status 
Report Function F.5.4 Generate 
System RMA Report Function 

F.6.0 Display Data Function F.6.5 
Display RMA Analysis Data 

Function F.4.0Analyze Data Function 
F.4.3 Compute System Ao/Ai based on 
RMA data 


System Configuration Data (APL, 

AEL, AAP,...) 

Data relative to system 
configuration such as APL, 
AEL, AAP, COSAL, COSBAL, 

etc... 

Function F.5.0 Report Data 
Function F.5.2 Generate Logistics 
Report Function F.6.0 Display 

Data Function F.6.1 Display Fleet 
Support Information Function 

F.6.1.3 Display Ship and System 
Info 

Function F.4.0Analyze Data Function 

F.4.1 Analyze Maintenance Data 
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System Mean Down Time (MDT) 

Data relative to ship 
system MDT 

Function F.5.0 Report Data 
Function F.5.3 Generate System 
Status Report Function F.5.4 
Generate System RMA Report 
Function F.6.0 Display Data 
Function F.6.5 Display RMA 
Analysis Data 

Function F.4.0Analyze Data Function 
F.4.3 Compute System Ao/Ai based on 
RMA data 


System Performance Trends by Ship 

Data relative to historical 
system performance 
trends by ship by baseline 

Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function 

F.5.3 Generate System Status 
Report Function F.5.4 Generate 
System RMA Report Function 

F.6.0 Display Data Function F.6.5 
Display RMA Analysis Data 

Function F.4.0Analyze Data Function 
F.4.2 Conduct System Performance 
Trending Analysis 


System Performance Trends Data 

Data relative to system 
performance trends 


Function F.6.0 Display Data Function 

F.6.2 Display Historical Fleet Data 

Function F.6.5 Display RMA Analysis 

Data 


System Status Reports 

Reports relative to ship 
system status 

Function Ext.Func.4.0 Display 
Aggregation Data 

Function F.O Provide Data Aggregation 
Capability Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function F.5.3 
Generate System Status Report Function 
F.5.4 Generate System RMA Report 


System RMA Reports 

Reports relative to ship 
system RMA 

Function Ext.Func.4.0 Display 
Aggregation Data Function F.7.0 

Print & Save Data 

Function F.O Provide Data Aggregation 
Capability Function F.5.0 Report Data 
Function F.5.4 Generate System RMA 
Report 


Tech Assist Cost per 
System/Ship/Year 

Data relative to cost spent 
for tech assist per system 
per ship peryear 

Function F.5.0 Report Data 
Function F.5.2 Generate Logistics 
Report Function F.5.4 Generate 
System RMA Report Function 

F.6.0 Display Data Function F.6.2 
Display Historical Fleet Data 

Function F.4.0Analyze Data Function 
F.4.4 Conduct Cost Analysis 


Tech Assist Metrics 

Data relative to tech assist 
metrics conducted by 
fleet support agents 

Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function 

F.5.3 Generate System Status 
Report Function F.5.4 Generate 
System RMA Report Function 

F.6.0 Display Data Function F.6.2 
Display Historical Fleet Data 

Function F.4.0Analyze Data Function 

F.4.1 Analyze Maintenance Data 
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Top Equipment Take Longest Time 

To Repair 

Data relative to a system 
orequipmentthat has the 
highest MTTR 

Function F.5.0 Report Data 
Function F.5.2 Generate Logistics 
Report Function F.5.3 Generate 
System Status Report Function 

F.5.4 Generate System RMA 

Report Function F.6.0 Display 

Data Function F.6.5 Display RMA 
Analysis Data 

Function F.4.0 Analyze Data Function 

F.4.2 Conduct System Performance 
Trending Analysis 


Top Replaced LRU with the highest 
Cost per System for last 5 years 

Data relative to a LRU that 
has the highest cost per 
system for last 5 year 

Function F.5.0 Report Data 
Function F.5.2 Generate Logistics 
Report Function F.5.3 Generate 
System Status Report Function 

F.5.4 Generate System RMA 

Report Function F.6.0 Display 

Data Function F.6.4 Display 
Logistics Information 

Function F.4.0Analyze Data Function 
F.4.4 Conduct Cost Analysis 


Training Data 

Data relative to ship 
personnel training 


Function F.6.0 Display Data Function 

F.6.2 Display Historical Fleet Data 
Function F.6.5 Display RMA Analysis 

Data 


Troubleshooting Lesson Learned 

Data relative to 
equipment 

troubleshooting lesson 
learned 

Function F.5.0 Report Data 
Function F.5.1 Generate System 
Assessment Report Function 

F.6.0 Display Data Function F.6.3 
Display Corrective Maintenance 
Information Function F.6.3.1 

Display Historical System 
Maintenance Action 

Function F.4.0 Analyze Data Function 

F.4.1 Analyze Maintenance Data 


User Enter Data 

Data is entered by the 

user 

Function F.O Provide Data 

Aggregation Capability Function 

F.1.0 Provide External Interface 

Function F. 1.1 Execute System 
Interface 

Function Ext.Func.3.0 Access Data 



Table 18. System Function Data Exchanges 
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APPENDIX C. RISK ANALYSIS THROUGH COSYSMO 


Figures 80, 81, 82, 83, and 84 diagram the results from the Cost Analysis 
performed by this group. Using COSYSMO software, the team conducted a Cost 
Analysis of what it would cost to create a new system and what it would cost to modify 
the current ESDS system. 
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NEW DS SYSTEM 


ESDS + 


NOTE: Inputs have RED Text. All 
other values are calculated. 



NEW REQUIREMENT? 

NEW EASY 

NEW NOMINAL 

NEW DIFFICULT 

Algorithms (New) 


I 

REUSE EASY 

1 

REUSE DIFFICULT 

NEW EASY 

I 

NEW DIFFICULT 

Algorithms (New) 





Requirements 

Definition 

Complexity 






I 

1 

I 









I 

1 

i 

R.1.1.1 

External Interface 

This system shall be capable of interface 
with other systems including human 
interface and data base to collect and 
provide necessary data to perform all the 
functions. 

DIFFICULT 


1 



1 





1 






1 




R.1.1.2 

Fleet Maintenance Support Data 
and Metrics 

Group Title 





















R.1.1.2.1 

Display a list of system/subsystem 
on each platform 

The system shall provide a list of 
system/subsystem on each platform. 

EASY 


1 

1 







1 




1 






R.1.1.2.2 

Display SME contact information 
for each system/subsystem 

The system shall display SME contact 
information for each system/subsystem 

EASY 


1 

1 







1 




1 






R.1.1.2.3 

Display a list of Open CASREP, 
Trouble Tickets, and Help Desk 
items open for a speciific ship or 
an entire Strike Group 

The system shall display a list of Open 
CASREP, Trouble Tickets, and Help Desk 
items open for a speciific ship or an 
entire Strike Group 

NOMINAL 


1 


1 






1 





1 





R.1.1.2.3. 

Search and Display CASREP data 
based on category, ship, element, 
system subsystem, sympton, status 

The system shall be able to search and 
display the CASREP data based on 
category, ship, element, system 
subsystem, sympton, and status 

NOMINAL 


1 


1 






0 


1 








R.1.1.2.4 

Display Area of Responsibility 
(AOR) requirements/standing 
Orders (Classified) for all platform 
in a Strike Group 

The system shall display Area of 
Responsibility (AOR) 
requirements/Standing Orders 
(Classified) for all platform in a Strike 
Group 

NOMINAL 


1 


1 






1 





1 





R.1.1.2.5 

Display outstanding/open CASREP, 

2 Kilo, Tech Assist Visit Request 

The system shall display 
outstanding/open CASREP, 2 Kilo, Tech 
Assist Visit Request 

NOMINAL 


1 


1 






1 





1 





R.1.1.2.6 

Display Technical Assist Visit 
Reports (TAVRs) by system 

The system shall display Technical Assist 
Visit Reports (TAVRs) by system 

EASY 


1 

1 







1 




1 






R.1.1.2.7 

Display the past and current ISEA 
investigations at the systems, 
equipment, and LRU levels 

The system shall display the past and 
current ISEA investigations at the 
systems, equipment, and LRU levels 

NOMINAL 


1 


1 






1 





1 






Display status on installed 
engineering alterations and 
engineering alterations under 

The system shall display status on 
installed engineering alterations and 

anninaarinn alfarafinnr unrlar 

EASY 


1 

1 







1 




1 







Figure 80. Function Count and Complexity Analysis 


210 












































NOTE: Inputs 
have RED Text 


NEW SYSTEM 

E5D5 + 



EASY 

NOMINAL 

DIFFICULT 

New Interface? 

EASY 

NOMINAL 

DIFFICULT 


Complexity 









MRDB 

DIFFICULT 




1 





FLTMPS/EPM COGNOS 

NOMINAL 



1 


1 


1 


CASREP DATABASE 

NOMINAL 



1 






AREA OF RESPONSIBILITY INFO 

NOMINAL 



1 


1 


1 


2 KILO DATABASE 

EASY 


1 







SAILOR TO ENGINEER 

NOMINAL 



1 


1 


1 


PMS 

DIFFICULT 




1 





INTERFACE DIAGRAMS 

NOMINAL 



1 


1 


1 


NSLC 

NOMINAL 



1 


1 


1 


NAYS UP 

NOMINAL 



1 






MFOM 

NOMINAL 



1 






ORTSTARS 

NOMINAL 



1 


1 


1 


Sum 

1 

9 

2 



6 



Figure 81. Interfaces Analysis 
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Figure 82. COSYSMO Size Multiplier Inputs for a New System 
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Results 


Cost and Schedule 
Effort =102 Person-months 
Schedule = 6 Months 
Cost = SSI 9347 

Effort Distribution (Person-Months) 
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Figure 83. Expert COSYSMO Output - ESDS+ 
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Figure 84. Expert COSYSMO Output - New System 
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APPENDIX D. PROJECT MANAGEMENT PLAN 


This appendix contains the Project Management Plan (PMP) for the NPS MSSE 
Distance Learning Cohort 311-1130. The PMP was prepared by the NSWC PHD 
Distance Support team during their first of three quarters of the capstone project. This 
document identifies and outlines the plan the Distance Support team used to conduct this 
research project. The team used the PMP to define project goals and objectives, plan and 
organize the effort and resources needed to accomplish the tasks necessary to complete 
the project, establish a system engineering approach, and to specify timelines for 
completion. The PMP was approved and signed by the Chair of the Department of 
Systems Engineering, Dr. Clifford Whitcomb on September 4, 2012. 

It is important to note that there have been a few modifications to the project plan 
since the PMP was signed and approved. For instance, the systems engineering (SE) 
process, shown in Figure 2 of the PMP, and the SE project activities, shown in Figure 3 
of the PMP, were both modified to ensure the project could be completed within the time 
allowed. Due to the time constraints and in order to provide a more in depth research 
project, the team decided to focus on the left hand side of the V-shaped SE model shown 
in Figure 2. The capstone team worked with and obtained approval from the stakeholders 
and project advisors to make the Stakeholder Requirements Definition, Requirements 
Analysis and Architecture Design technical processes the focal points of the project. The 
updated SE model can be seen in Figure 4 of the capstone report. In terms of the SE 
project activities, shown in Figure 3 of the PMP, the team worked with the stakeholders 
and advisors to modify and focus on a portion of the activities. The team completed 
Activity 1.0, Define Stakeholder Needs, and its sub-activities, Activity 2.0, Requirements 
Analysis, and its sub-activities, and Activity 3.0, System Architecture Design, and its 
sub-activities. The updated SE project activities can be seen in Figure 5 of the capstone 
report. 
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L INTRODUCTION & PROJECT OVERVIEW 


Ill is is the capstone Project Management Plan (PMP) for the Naval Postgraduate 
School (NPS) Masters of Science in Systems Engineering (MSSE) distance learning 
cohort 311-1130. This project management plan lays out the organizational and 
technical approaches the team will use during the course of the project. Specifically, the 
PMP describes the specific problem or issue that the project will address, the project 
objectives, llie systems engineering approach, the technical and programmatic activities 
planned, and the team's organization. It will also present the project schedule with major 
milestones and deliverables (NFS 2006). 

A. BACKGROUND 

Requirements of homeland defense* national security, and the war on terrorism 
have made a ship's mission more critical than ever (Office of Homeland Security 2002). 
When equipment fails there is little time to wait tor engineers or technicians to fly to the 
deployed ship to help resolve the problem. By hringing leading-edge distance support 
technology to our sailors at sea, twenty four hours a day, seven days a week, the 
engineers, logisticians, and technicians of Naval Surface Warfare Center, Port Huencme 
Division (NSWC PHD) are working to help our ships return to operational readiness 
without leaving their positions. Distance support is important due to (Camanag 2012): 

* Reduced-Manned Ships (such as the Littoral Combat Ship [LCS]) 

* Increasing complexity of systems due to technology advancements, 
integration of emergent capabilities, and Foreign combat system elements 

* Pressures to reduce Total Ownership Cost (TOC) 

Current distance support is often slow and ineffective. Numerous distance 
support tools exist but need to be consolidated and or integrated more effectively. In 
addition, distance support activities <ire often not captured for knowledge retention and 
reutilization. Knowledge that is captured is difficult to access and utilize in a timely 
manner. Better tools need to be developed to allow knowledge to be captured and 
utilized when needed to help improve distance support and ultimately fleet readiness. 
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Tliis capstone team will investigate the requirements and parameters needed to 
provide a technically feasible, cost effective, and efficient approach for N$WC PHD to 
provide distance support to the United States Navy (IJSN). lliis project will investigate 
improvement options for providing distance support to the fleet. In addition to helping 
the fleet, it will benefit the command, NSWC PHD, which all team members represent. 

B, PROBLEM STATEMENT 

1. Initial Problem Statement 

When this capstone project was started, the initial problem statement was: A 
decline in sailors' ability to operate, maintain, and sustain combat systems necessitates 
the need to optimize distance support from Fleet field support activities to meet current 
and future Fleet Readiness demands (SEA 21 2010), As new surface ship programs 
emerge, the complexity of combat systems has increased. In recent years, the Navy has 
identified reducing manning levels as a key approach to reduce costs. The Navy’s 
decision lo reduce manning dropped the Fleet's availability levels to “below the levels 
required to support material readiness requirements” (Balisle 2010). Inadequate distance 
support results in reduced fleet readiness, increases shore activity and Subject Matter 
Expert (SME) manpower requirements, decreases fleet independence, decreases 
efficiencies, and increases total ownership costs. 

After further investigation and research, the team discovered that fleet distance 
support covers a wide area of ships operation and maintenance. The Commander of 
Naval Surface Forces (CNSF) defines distance support as: “Distance support is a Navy 
Enterprise effort that combines people, processes, and technology into a collaborative 
infrastructure without regard to geographic location/" and “distance support projects 
reactive, proactive, and predictive support to sailors across functional areas in order to 
achieve the right readiness at the right time, at the right cost' 1 (CNSF 2010). 

The CNSF categorizes distance support by the following four functional areas: 

* logistics 

* Maintenance and Modernization 

* Manpower, Personnel, Training and Education (MPT&E) 
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* War fighting 

In addition, each of the four categories listed above also have many sub functions 
and unique processes. Hie magnitude and volume of fleet distance support activities that 
occur across these functional areas is enormous, The team soon realized that a capstone 
project that improves fleet distance support across all four functional areas is beyond our 
ability given the limited resources and time to complete the project. The team agreed that 
the project had to bo scoped to a manageable level, so it was re-focused to the distance 
support areas that NSWC PHD currently supports. NSWC PHD is primarily involved in 
limited aspects of logistics, maintenance, and modernization of combat systems installed 
on surface ships. Since most of the team’s work is related to maintenance, the team 
limited the scope to maintenance functions. 

2, Reused Pujblein Statement 

NSWC PHD has several methods for conducting distance support for ship 
maintenance. NSWC PHITs capabilities include both remote systems monitoring and 
technical assistance (tech assist), Both services are provided in real time, near real time, 
and oil a periodic basis. Each of these levels of distance support has unique processes 
and requirements which again would require significant investigation and research. 

Since time was of the essence, the team decided to seek guidance from several 
stakeholders to help scope the project. After meeting with several key stakeholders at 
NSWC PHD, the team decided to focus on improving distance support knowledge 
capturing and knowledge reutilization primarily because a solution was needed to 
aggregate data from multiple distance support data collection sources. The stakeholders 
advised that they were specilically interested in capturing and maximizing the reuse 
potential of distance support activities and experiences to increase Heel self-help and 
improve equipment reliability thru design changes and new manufacture of combat 
systems. 

Therefore, with the stakeholder preferences in mind, the team revised the problem 
statement as follows: 
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NSWC PHD needs to improve distance support knowledge capturing in order lo 
^utilize this knowledge to provide more effective distance support capability to 
the Heel and perform more effective trend analysis to improve equipment 
reliability utilizing existing shore support resources and processes (Scheid et al 
2G12) r 

C. PROJECT SC OPE 

The team lias scoped the project to focus on the area of improving distance 
support knowledge capturing and reutilization, as it applies to NSWC PHD. The team 
will apply a system engineering approach and techniques to clearly define the problem, 
deline and prioritize stakeholder requirements, determine the measures of effectiveness 
perform a functional analysis, research and compare possible solutions, and develop 
conclusions and recommendations. 

As the revised problem statement suggests, the learn will focus on finding a 
solution to determine what methods and lools are needed to allow distance support 
knowledge and experience to he captured and utilized to help improve distance support 
and ultimately fleet readiness, llierefore, the team will focus primarily on developing a 
solution that will aggregate data from numerous existing distance support sources and 
export data lo the fleet lo promote self-help and export data to help facilitate trend/failure 
analysis opportunities. 

Below is a list of initial research questions that will be pursued for I his capstone 

project: 

• What are the specific fleet needs for distance support? 

■ What tools and processes currently exist? 

• What technology is available to modernize and evolve distance support 
capabilities? 

• What methods/approaches have other organizations successfully 
implemented? 

• What tools/technology have other organization successfully utilized? 
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Expected deliverables include a formal system engineering report and presentation. 
The team will also provide recommendations for implementing solutions that will meet 
stakeholder expectations. Resources, at a minimum, will include existing distance 
support processes and tools, past distance support studies, and interviews from personnel 
currently responsible for managing and conducting distance support. 

IX PROJECT OBJECTIVES, CONSTRAINTS, & ASSUMPTIONS 

Ihere are two main academic objectives of the capstone project. The first is to 
apply the system engineering knowledge, skills, and techniques acquired in the NPS 
MSSE curriculum to solve an applicable real world problem. The second is to 
successfully complete the capstone project, including delivering all academic and 
stakeholder deli verables, within the given lime frame. 

He low is a list of project constrain Is: 

■ The project must be completed in 3 academic quarters. 

* The project must he accomplished within the time and manpower 
available. 

* The project must he accomplished without incurring any monetary costs. 

■ Deliverables must meet NPS guidelines. 

Below are the assumptions made to guide the project: 

* Hi ere is significant benefit to improving distance support knowledge 
capturing and reutilization, 

* [here are better methods and/or better tools for capturing and re utilizing 
distance support knowledge. 

* Demand for distance support will increase or remain constant. 

* Regional Maintenance Centers (RMC) and/or In Service Engineering 
Agents (ISEA) technical expertise is stable. 

* RMCs/ISEAs arc committed to distance support knowledge capturing and 
re utilization. 
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ORGANIZATION STRUCTURE WITH ROLES & RESPONSIBILITIES 


The team is organized by competency areas to support the capstone project, as 
shown in Figure 1. 



Fig u re I, Organ izal ion Chart (After Kerzner 2011) 
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1 . 


NFS Advisors 


Advisors shall guide students in the formulation of project topics, guide students 
in the development of the PMP and the Capstone Project Report, help identify project 
sponsors when appropriate, help lay out a schedule of milestones, monitor the students' 
progress, provide consultation and direction, and review documents for accuracy and 
completeness and products which result from the project (NFS 2006). 

2, Technical Roles 

The systems engineering product development responsibilities, as shown in 
Figure 1, show which product areas each team member is responsible for during the 
project development. lire product development responsibilities are divided into six 
system engineering principals: requirements engineering, architecture design, software 
design, integration and testing, cost analysis, and risk management 

• Requirements Engineering - Responsible for the iterative elicitation, 
elaboration, verification, and documentation, and evaluation of all 
capstone project requirements. 

• Architecture Design - Responsible for the development and design of the 
system architecture. Creates the Dq-^rt merit of Defense Architecture 
Framework (DoDAF) views arid documents the architecture artifacts. 
Translates stakeholder needs and objectives into system functional 
requirements and decomposes these requirements into functional 
architecture. Performs functional arid gap analysis to determine which 
data and software tools that are required to he integrated into the data 
aggregation system. An Analysis of Alternatives (AoA) will also be 
conducted to detenuine the alternate solutions for the data aggregation 
system based on the cost analysis and performance effectiveness of each 
alternative system. 

■ Software Design - I>evelops or improves existing software tool that will 
aggregate data from numerous existing distance support sources and 
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export data to the fleet lo promote self-help and export data lo other tools 
to help facilitate trend/failure analysis opportunities. 

* Integration & Testing - Responsible for conducting any necessary system 
integration and testing that may occur during Modeling & Simulation 
(M&S) to make sure the system performance meets its requirements based 
on Key Performance Parameters (KPP). Integration and testing may also 
occur during the design and implementation of the selected architecture, 

* Cost Analysis - Responsible For all cost related analyses, including 
conducting a Business Case Analysis (BCA) and provides Return or 
Investment (ROI) estimation. 

* Risk Management - Responsible for conducting risk management, 
performs risk assessment and provides risk mitigation. 

3, Administrative Roles 

'Flie project management responsibilities, as depicted in Figure 1, show which 
overarching tasks each team member is responsible for during the project development. 
The project management responsibilities are divided into five categories: project lead. 
Work Breakdown Structure (WBS) lead. Configuration Management (CM) lead, 
technical editor (Tech. Editor), Systems Engineering (SE) and I luman Systems 
Integration (FIS I), and Administration (Admin). 

* Project Lead - Acts as the overall visionary and monitors the progress 
toward meeting capstone project objectives. The project lead is 
responsible for managing and executing the project according lo the 
project plan and to maintain a balance between tire technical, schedule, 
and administrative requirements of the pmjeet and die organization of 
team efforts. The project leader's responsibilities include: facilitate team 
meetings and information exchange, monitor and guide the overall project 
activities, foster team member participation, mid promote collaboration 
among the team members. 

* WBS Lead - Responsible for creating, tracking and monitoring the WBS 
through the project term. 
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CM Ijead - Responsible for ensuring all products created by the group 
follow a proper change process to ensure consistency in review and 
certainty of content. 

Technical Editor - Ensures all the technical reports and publications 
generated by the team will meet the style guide and well written. 

SE & HSI Lead - Verifies that sound systems engineering principles, 
techniques mid theory jure utilized in all tasks associated with the project. 
Also responsible for ensuring human factors are considered during the 
proj ect. 

Administration - Responsible for taking notes during team meeting and 
keeping track of action items, keeping minutes of meetings, assembling 
drafts, consolidaling inputs to all project documents, and managing the 
data repository. 



STAKEHOLDERS 


F, 

A list of potential stakeholders and the team’s best estimate of their primary 
concern with regards to this project is given in Table 1 below. 


Stakeholder 

Primary Concern 

Fleet 

Improve fleet readiness, redueo TOC 

Waterfront Activities 

Improve distance support capabilities, capture 

knowledge 

USN Type Commander (TYCOM) 

Improve fleet readiness* DS effectiveness. System 

Performance Metrics 

Naval Sea Systems Command 

(NAVSEA) 

Improve distance support capabilities, reduce Life 
Cycle Cost (LCC). System Performance Metrics. 

Failure Trends 

Naval Surface Warfare Center, Pori 

Ilueneme Division (NSWC PHD) 

Improve fleet readiness, improve distance support 
capabilities, capture knowledge, and reduce 

LCC/TOC 

Program Executive Office (PFO) 

Improve distance support and reduce TOC, Failure 

Trends, Acquisition Impacts 

Office of the Chief of Naval Operations 

(OPNAV) 

Improve fleet readiness and reduce TOC 


Table 1 . Stakeholders 
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PROJECT SPONSORS 


All the sponsors are from NSWC PHD. The sponsors Tor this capstone project are 
listed in Table 2. 

Sponsor Title 

M r. T ini othy T roske Teelmi c al Direc t or 

CAPT Theodore Olson Office of logistics (OOL), Deputy Commander 
Mr. Fabio VStale Office of I x>gisties (OOL). Director 

CAPT (Scl) Scott Davis Chief Engineer (CHENG), Office of Engineering 
Technology (OET) 

Mr. David S die id OET. Knowledge Management and DS Advocate 

Mr. David Willi a ins OET DS Community of Practice Lead 

Ms. t 'oralvn Akers Fleet Liaison 

Mr. John Lester SE - A Department l^ead 

IS 1 1 '. Noel Cain a nag SE - L Deparlment I 

Mr. James Childs SE - S Department lx:ad 

Table 2, Project Sponsors 
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II. SYSTEMS ENGINEERING APPROACH 


A. OVERVIEW 

The team will adopt the new 2009 DoD SK Model (DAU 2011) as shown in 
Figure 2 below, as a framework for the project systems engineering process due to its 
standard applicability to system engineering projects. The 2009 DoD SE Model consists 
of two major processes; the technical management processes form the executive or 
control logic that steers system development to meet project or phase objectives. The 
technical processes are depicted in a V-shaped pattern. This pattern portrays the top- 
down design that occurs iis requirements <ire progressively allocated from the system 
level down to lower-level elements. In addition, the Y-shaped model of the technical 
processes more explicitly shows the bottom up realization from lowest level components 
to higher assemblies to achieve the complete system. The technical processes are applied 
iteratively and recursively across the I lie cycle and at different levels m the system 
hierarchy to elaborate and mature the system. 





Implementation 



Figure 2. 2009 DoD System Engineering Model (From DAU 2011) 
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The learn will use Hie tailored SE process as illustrated in Figure 3 below lbr 


activities in the development of the capstone project. 
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Figure 3 . 


SE Process to Project Activities (Alter DAU 2011) 


If- TECHNICAL PROCESSES 

L Define Stakeholder’s Needs 

The llrsl step of the SE process is to conduct interviews with users and 
stakeholders to determine the needs, requirements, and objectives for the use of data 
aggregation system using the data products generated from the shore support 
infrastructure. From the interviews, the learn will also develop a Concept of Operations 
(CONORS), 


2, Requirements Analysis 

During this phase, the team will define the distance support functional and 
performance requirements, sueh as the Key Perf ormance Parameters (KPP) of the system, 
based on the stakeholder’s needs analysis. The team will then conduct the research and 
create a list of existing DS functions and systems currently used in the fleet, which 
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include the data products that are generated from each function and system. These 
existing functions will then he mapped against the functional requirements based on 
stakeholder’s needs to determine if there are any capability gaps. 

The team will also develop the test and evaluation strategy which will be used in 
the system verification and validation phase later in the process based on the developed 
functions and requirements. 

3, System Architecture Design 

In this phase, the team will develop the detailed architecture design of’the system 
by decomposing the functions using hierarchy structure and publish the results in 
compliance with the Department of Defense Architecture Framework (DoDAF). Hie 
Functional Flow Block Diagram (FFBD). which is a multi-tier, lime-sequenced, step-by- 
step flow diagram of system’s function flow, will be used to provide an easy-to-follow 
graphical representation for illustrating the system based on its functional elements, lire 
FFBD will serve as the System Functionality Description (SV-4a) model. Also, a 
functional allocation matrix will be created to accompany the SV-4a 7 as this will help to 
map system functions to system elements. 

Following the development of the architecture, the team w ill then conduct an 
Analysis of Alternatives (AoA) to determine alternate solutions. In conducting the AoA, 
a basic cost analysis of all options will be conducted to help determine the most feasible 
and cost effective, Before system implementation, a more substantial cost analysis will 
also he performed to determine the cost effectiveness as well as the ROI benefits for 
implementing the chosen alternative system. 

4. System Implementation 

As authorized by the command sponsor, the team is allowed to use the existing 
hardware available at NSWC PFID for system implementation. During this phase, the 
team will develop or improve existing software tools such as database and other analysis 
tools which will be used for data aggregation as defined in the architecture design phase. 
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5. 


System Integmtinti 


In this phase, the team will assemble all the data and software modules and 
integrate into the system in preparation Tor system verification and validation phase. 
Integration and testing will occur during M&S and possibly during design and 
implementation of the selected architecture, ITie team will model candidate solutions, as 
applicable, and test for compatibility and performance. Numerous data sources currently 
exist so the modeling processes will attempt to integrate data from multiple sources into a 
single system so that data can be collected and utilized to satisfy requirements. Once 
integrated, the system should be capable of providing information that can be used to 
improve sailor sell-help and used to improve equipment reliability. 

6, System Verification and Validation 

During this phase the system will be tested against Verification & Validation 
requirements defined in the requirements analysis phase to make sure the products will 
satisfy the stakeholder's needs. Any discrepancies and issues with the design that 
captured during this phase will be debugged, corrected, and rc-designed. 

7, Deploy 

As desired by the command sponsor, the system desired will be a common tool 
across all NSWC PHD supported systems. These systems include combat systems (e.g. 
AEGIS), weapons (e g. MK 38 Machine Gun System (MGS)}, radars (e g. SPQ-9B 
radar), Hull Mechanical and Engineering (HM&E) systems (e.g. MK 41 Vertical Launch 
System (VLS)), equipment groups (e g. switchboards), other systems (e,g. Collaborative 
Engagement Capability (e.g. CEC)). and Force protection (e.g Acoustic Hailing Device). 
With many systems under consideration, the plan is to select a specific system from 
which to perform a beta test. A community of stakeholders w ill be solicited to be a part 
of the lest, which is expected to provide feedback such as user interface to overall logic 
and usefulness. Upon satisfactory completion by the command sponsors, the feedback 
w ill be adjudicated, and the product will evolve to include all the systems under NSWC 
PHD purview. 


16 


241 



TECHNICAL MANAGEMENT PROCESSES 


C. 

The capstone project requires management in several areas of concern. 
Management is required to ensure the end product is completed on schedule and to the 
satisfaction of stakeholders and NFS. These areas of concern are project risks, 
configuration, and information assurance. 

1. Risk Management 

Risks to this project will primarily he managed in accordance with the Risk 
Management Guide for DoD Acquisition (DoD 2006). Although written in general 
terms, It will he tailored to this project. Figure 4 describes the process promulgated in the 
guide: It is important to note the focus on mitigation or control aspect Project 
management can also use acceptance, avoidance and transfer strategies lo respond to 
risks (Kerzer 2009. 784). 



Rtsk 

Mitigation 

Plan Implementation 


Figure 4, Risk Management Process (From DoD 2006) 
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Reporting each ri sk 1 dentifi ed will be performed through th e use of a risk m atrix 
shown in Figure 5 below, which classifies each risk by likelihood and consequence. 
When project risks need to be conveyed to capstone professors or stakeholders, this 
reporting matrix will be used. 



Consequence 


Figure 5. 


Risk Assignment Matrix (From DoD 2006) 


The consequence for a risk will be determined by using Table 3 below. 


Level 

Schedule 

1 

Minimal or no impact 

2 

Able to meet key dates 

Slip < 1 week 

3 

Minor schedule slip. Able to meet 

key milestones with no schedule float 

Slip < 2.5 weeks 

4 

Program critical path affected 

Slip < 1 month 

5 

Cannot meet key program milestones 

Slip > 1 month 


Table 3.Risk C onsequence Classification (After D oD 2006) 
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The likelihood of each risk will be determined by using Table 4 below. 


Level 

Likelihood 

Ih'abahdity of Occurrence 

1 

Not Likely 

<10% 

2 

Low likelihood 

<30% 

3 

Likely 

<50% 

4 

Highly likely 

<90% 

5 

Near Certain 

<100% 


Tuhlc 4 Risk Likelihood Classification (After DoD 2006) 


Response to risk by controlling, transferring or avoidance will be designed to 
lower probability, severity or both. This would be reflected in a new risk matrix that 
could move risks in the "red" boxes to "yellow" or "green". The last option, acceptance, 
will not change the risk matrix; it is used for a risk that is tracked but no course of action 
is developed until occurrence happens. 

2. ('onfiguration Management 

The team will use Dropbox™ ( \vwvv.dronbox.com ) and Sakai® as archive tools 
throughout the project. The deliverables will be in the form of Microsoft (MS) Word® 
documents, MS Excel® spreadsheets, MS Power Point® presentations, drawings, and 
architecture artifacts dcvcloped in CORE®. The revision process will be tracked using 
the file name with an incremented alpha numeric number with the team member's initial 
(Le., PMl 1 Draft Rev A HT). Once a deliverable is ready for submission it will be 
published using numeric revisions (i.e., PMP Rev 1). The numeric revision number will 
be incremented upon subsequent submissions (i.e., PMP Rev 2). All revisions will be 
maintained chronologically in an archive. Ill is archive will he maintained by the 
technical editor. 
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RESOURCES 


To assist in this project, a number of software toots will be utilized, which include 
but are not limited to: 

• System Architecture {CORE©) 

• Data Storage (Dropbox) 

• Research (Dudley Knox Library) 

• Database Development (SQL Server©) 

• Statistical Analysis (MATLAB®) 

• Modeling & Simulation tools (ExtendSim©) 

• Microsoft® (MS) Office Suite (Word®, Excel©., Power Point©. Outlook©. 
Project®, and Access®) 

• NPS Thesis Project Office Website 

• Sakai® 
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m. MILESTONES AND DELIVERABLES 


fhe milestones associated with the capstone project are listed in t able 5 below. 
Every milestone represents an important achievement in the capstone project. Through 
each of the listed milestones, the team will show progress and advancement with the goal 
of completing all listed deliverables within the given timeframe. The capstone Project 
will span for three academic quarters. At the end of each quarter, the learn will use an In- 
Process Review (IPR) as a forum to brief NPS faculty and stakeholders on the project’s 
status and progress and to present deliverables completed up to lhal point in time. 

At the end of the first academic quarter, the team will present an overall view of 
the project, using the PMP as a reference, during the first IPR. The products included in 
the PMP will be used to present the projects scope and objectives, team’s organization, 
systems engineering process, and technical and programmatic activities planned to 
successfully complete all listed deliverables. Furthermore, the team will present a 
comprehensive stakeholder need analysis; including a detailed explanation of the process 
taken to determine needs, requirements, and objectives from stakeholders. Additionally, 
a detailed requirements analysis will be presented to show how the team used the 
stakeholder needs to translate them into specific functional and performance requirements 
as part of the requirement analysis. Finally, a gap analysis wi II be completed and 
presented during the first IPR. 

The plan is for the team to complete the system architecture design by the end of 
the second academic quarter. The architecture design will be presented using DoDAF 
artifacts during the second IPR. Additionally, tire team will complete and present an 
analysis of alternatives, cost analysis, and risk management plan to NPS faculty and 
stakeholders. Moreover, M&S will be completed by the team and results will be 
presented during the second IPR. 

During the final third portion of the project, the team will develop or improve 
existing software systems based on the system architecture design. Furthermore, the 
team will perform system integration in preparation for the system validation and 
verification phase. The validation and verification phase will be then completed to 
ensure the system was built right and to verify the right system was developed. Once the 
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validation and verification phase is completed, a system prototype will be ready to 
present to NPS faculty and stakeholders. All completed deliverables, products, and 
artifacts developed up to this point will be included in the final capstone project report 
and will be presented during the final IPR. 


Milestones 

Deliverables 

Completion Date 

Final Project Management 

Plan Due 

Project Management Plan 

09 August 2012 

In-Process Review No, 1 

Stakeholder Need Definition and 

Requirements Analysis 

13 September 2012 

In-Process Review No. 2 

System Architecture Design 

(DoDAF Artifacts), Analysis of 

Alternatives, Modeling and 

Simulation, and Risk 

Management Plan 

06 December 2012 

Final Report Due to Advisors 

Draft Capstone Project Report 

14 February 2013 

Final Report Due to Thesis 

Processing Office 

Final Capstone Project Report 

28 February 2013 

Final In-Process Review 

System Prototype and Final 

Capstone Project Presentation 

14 March 2013 

Final Report Due to 

Department Chair 

Final Capstone Project Report 

15 March 2013 


Table 5, Milestones and Deliverables 


The preliminary schedule of major events for this capstone project is depicted in 
Figure 6. The schedule also captures the initial deliverables as outlined in the Capstone 
Project Guide (NSP 2006), The schedule will he further developed throughout the 
duration of the project and each of the major events will be broken down to show 
additional detail for each of the tasks required to complete all deliverables. 
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ID 

. 

Task tome 

Duration part pnfsh 

Predec 

1 


Distance Support Casptone Project 

ISO days Mon 7/16/12 Fri 3/22/13 


2 

✓ 

Initiate Project 

17 days Mon 7/16/12 Tue 8/7/12 


7 


Status Update (Sign 143 on Sakai) 

95 days Thu 7/19/12 Thu 11/29/12 


27 


PMP Development 

IS days Mon 7/16/12 Thu 8/9/12 


33 


Stakeholder Requirements Definition 

145 days Mon 7/16/12 Fri 2/1/13 


34 


Identify Stakcholdcr(s) 

5 days Mon 7/16/12 Fri 7/20/12 


35 


Define Stakeholder Needs 

5 days Mon 7/23/12 Fri 7/27/12 

34 

36 


Conduct Stakeholder Surveys 

10 days IVbn 7/30/12 Fri 8/10/12 

35 

37 


Categorize Survey Data 

10 days Mon 8/13/12 Fri 8/24/12 

36 

38 


Develop System GONOPS 

10 days IVbn 1/21/13 Fri 2/1/13 

78 

39 


Requirements Analysis 

45 days Mon 8/27/12 Fri 10/26/12 


40 


Define DS Functional Requirements 

10 days Mon 8/27/12 Fri 9/7/12 

37 

41 


Define Performance Requirements 

10 days Mon 9/10/12 Fri 9/21/12 

40 

42 


Create List of Existing DS Systems 

15 days Mon 9/24/12 Fri 10/12/12 

41 

43 


Conduct Gap Analysis 

10 days Mon 10/15/12 Fri 10/26/12 

42 

44 

■ 

Develop T&E Strategy 

10 days Mon 9/3/12 Fri 9/14/12 


45 


IPR#1 

10 days Fri 8/31/12 Thu 9/13/12 


48 


System Architecture & Design 

90days Mon7/23/12 Frill/23/12 


49 


Develop System Architecture Using DoDAF 

45 days Mon 7/23/12 Fri 9/21/12 


66 


Conduct AoA 

20days Mon 10/29/12 Frill/23/12 

43 

67 

■ 

Perform Cost Analysis 

10days Mon 10/29/12 Frill/9/12 


68 


Risk IVfenagement 

20days Mon 10/29/12 Frill/23/12 


71 


Perform IVbdeling and Simulation 

15 days Mon 9/17/12 Fri 10/5/12 

44 

72 


IPR#2 

10 days Thu 11/22/12 Thu 12/6/12 


75 


System Development & Implementation 

20 days Mon 11/26/12 Fri 12/21/12 


76 


Build and Develop the System 

20 days Mon 11/26/12 Fri 12/21/12 

48,6 

77 


System Integration 

20 days Mon 12/24/12 Fri 1/18/13 


78 


1 ntqgrate all Data/Modules into the System 

20 days Mon 12/24/12 Fri 1/18/13 

76 

79 


System Verification and Validation 

20 days Mon 2/4/13 Fri 3/1/13 


80 


Verify and Validate System to Meet KPP 

10 days Mon 2/4/13 Fri 2/15/13 

38 

81 


Debug and 1 improve the System 

10 days Mon 2/18/13 Fri 3/1/13 

80 

82 


Deploy 

10 days Mon 3/4/13 Fri 3/15/13 


83 


Demostrate System Capability 

10 days Mon 3/4/13 Fri 3/15/13 

81 

84 


Final IPR 

25 days Thu 2/7/13 Thu 3/14/13 


88 


Casptone Report 

180 days Mon 7/16/12 Fri 3/22/13 



Figure 6. Schedule 
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